Not sure which flow to use for this scenario: I have a Scala process running in my backend, that needs to talk to an API. This process is not exposed to the outside world and there is no user involved. I created a Non-Interactive-Client for making the calls and everything works fine. However, I would like to get a refresh token so I could automatically refresh the access-token, and this doesn’t work. I’m using the Java AuthAPI object to request a token, and if I do:
auth.requestToken(audience).setScope(“offline_access”).execute()
I get an error saying “Client has not been granted scopes: offline_access”.
The API is configured to “Allow Offline Access”, and the client is configured with grant-types Implicit, Authorization Code, Refresh Token and Client Credentials.
Am I doing it wrong? Is there something else to configure?
Refresh tokens are only available when implementing an [Authorization Code Grant] (Call Your API Using the Authorization Code Flow), [Authorization Code Grant (PKCE)] (Call Your API Using the Authorization Code Flow with PKCE) or [Resource Owner Password Grant] (Call Your API Using Resource Owner Password Flow), as stated in the [refresh token documentation] (Refresh Tokens).
As per the specification, a refresh token SHOULD NOT be included in the response for the client credentials grant. You can read more about it here: RFC 6749: The OAuth 2.0 Authorization Framework
Since you’re implementing [server-to-server auth] (Call Your API Using the Client Credentials Flow), there is no real need for refresh tokens, since the credentials are not exposed to the end user and you can just retrieve new tokens once the previous ones expire.
Hi Ricardo, thanks for the answer. It’s true that I can just ask for new tokens (this is how I ended up implementing it), but just to clear up my confusion around the different authentication flows: my code that requires authentication is not open to the world at all, it actually runs inside a Kubernetes pod with no exposed ports. So there are no security concerns regarding the refresh token. If I understand correctly, the right auth-flow for this scenario is Client Credentials Grant. But then, why not return a refresh-token as well…? I understand that it’s not necessary but I’m just curious.
It is not returned specifically because the specification states that it should not be returned. In your case, the client credentials grant would have no benefit from the refresh token, as it does not add anything new that you don’t already have in your implementation, since storing the refresh token would have the same value as privately storing the credentials for the authentication request.