OAuth Client Credential Flow - Refresh Tokens

Question

The Scenario

I've recently built an API, and have protected its resources using OAuth Bearer Access Tokens.

I've used the Client_Credentials Flow, as it will be accessed by clients as opposed to users.

Here's the thing, when a client has successfully provided the client_id and the client_secret they receive a response like the following :-

{
  "access_token": "<Access Token>",
  "token_type": "bearer",
  "expires_in": 1199,
  "refresh_token": "<Refresh Token>"
}

Refresh Tokens.

Not knowing much about refresh tokens, i immediately assumed that a client would be able to provide the OAuth Server the refresh_token to retrieve a fresh Access_Token.

This is 'kind of' correct.

In order to use the refresh_token the client still needs to pass the client_id and client_secret along with the refresh_token to get a new access token.

The grant_type also needs to be changed to refresh_token.

Where is the benefit of a refresh_token using this flow? If I need to pass the client_id and client_secret each time, surely you would just avoid using a refresh token altogether?

Shiverick

This question has nothing specifically to do with C#/ASP.Net and it applicable to anyone building an OAuth2 API. I have edited it to make it more widely applicable. (Great question!) – Quintal

Answer 1

The issuance of a refresh token with the client credential grant has no benefit. That is why the RFC6749 section 4.4.3 indicates A refresh token SHOULD NOT be included. Thus its issuance is at the discretion of the authorization server.

From my point of view an authorization server should never issue a refresh token with the client credentials grant as the access token issuance process will take an additional and unnecessary step:

• The issuance of he access token with the client_credentials grant type is done on the first request.
• The issuance of he access token with the refresh_token grant type is done after at least two requests, depending on the way you issued to first access token.

Wengert

Thank you, finally an actual reference to a specification which explains why using refresh token doesn't make sense with client_credentials. We were in doubt, now it's clear! – Pothead

But does it make sense to use refresh tokens in the context of the question: " it will be accessed by clients as opposed to users." clients as in third parties, with no user interaction to renovate refresh/access tokens? – Marks

A client can receive access tokens with its credentials. Why would you store and manage refresh tokens when you don’t need them to issue an access token? – Wengert

@Marks I agree. Using refresh tokens are more secure than using ClientId and Secret for retrieving new tokens. – Opt

@Opt really? If your client credentials are not secure you should really care about it because every single requests to the authorization endpoint require confidential client authentication. In any case, to get a new access token with your refresh token, you will be required to send your client credendials as well. So what's the point storing a refresh token when you can get an access token directly? – Wengert

@Wengert I see. That would make refresh tokens utterly pointless if one needs to include both the ClientId and Secret. Apparently "there is a standard compliant way to request an access token without transmitting the client secret: RFC 7523 and OpenID Connect define a method for authenticating with a JWT instead of a client secret sent in plain text. The JWT can be either HMACed with the client secret or signed with the client’s private key.". So there may be hope. – Opt

Yes RFCs 7521/7522/7523 and RFC8705 are the ways to go if you want to get rid of passwords sent as plaintext. Unfortunately, these features are not really implemented on authorization servers side or supported by clients. – Wengert

Answer 2

In Authorization Grant flow Refresh Token act as temporary credentials held by a Client in behalf of the Resource Owner.

Note that a Client can hold multiple refresh tokens for various Resource Owners. This is really important because this is why you need Refresh Tokens. Additionally note that the client must be authenticated as stated in the rfc.

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server.

Therefore once trading a Refresh Token for an Access Token the client must authenticate with it's client_id + client_secret (in authorization bearer) + it must send a valid refresh token. Again the Client can do this for multiple resources and for each Resource Owner (and scope) there will be a different Refresh Token (that was previously exchanged by an Authorization Token), nevertheless the Client always authenticates with the same credentials (for the same Authorization Server).

Regarding the Client Credentials flow it specifically states A refresh token SHOULD NOT be included as said in top response.

A Refresh Token is not needed because the Client is also the Resource Owner, or at least has full access to the resources granted by the Access Token. That way it is enough just to authenticate with client id and client secret. You could state that that you cannot revoke the Refresh Token and that might be the only case a Refresh Token would be useful. Nevertheless some Authorization Server still return a Refresh Token on the Client Credentials Grant.

Orville

Answer 3

The benefit is that he request token normally has a much longer life span than the access token.

Access token is used in communicating with the resource server. Request token is used when communicating with the authorization server.

You could read this as that you may be authorized but that the exact extend of your authorization needs to be reevaluated from time to time. So request token has it use.

Toolis

By "request token", do you mean refresh token? – Marilyn