30

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?

Chuck Le Butt
  • 47,570
  • 62
  • 203
  • 289
Derek
  • 8,300
  • 12
  • 56
  • 88
  • 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!) – Chuck Le Butt Feb 27 '21 at 19:30

2 Answers2

49

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.
Spomky-Labs
  • 15,473
  • 5
  • 40
  • 64
  • 4
    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! – Cécile Fecherolle Oct 16 '20 at 10:53
  • 2
    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? – Anonymous May 18 '21 at 21:09
  • 2
    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? – Spomky-Labs May 18 '21 at 21:29
  • 1
    @Anonymous I agree. Using refresh tokens are more secure than using ClientId and Secret for retrieving new tokens. – TheLegendaryCopyCoder Jan 25 '22 at 12:08
  • 1
    @TheLegendaryCopyCoder 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? – Spomky-Labs Jan 25 '22 at 12:14
  • @Spomky-Labs 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. – TheLegendaryCopyCoder Jan 25 '22 at 12:22
  • Yes RFCs [7521](https://datatracker.ietf.org/doc/html/rfc7521)/[7522](https://datatracker.ietf.org/doc/html/rfc7522)/[7523](https://datatracker.ietf.org/doc/html/rfc7523) and [RFC8705](https://datatracker.ietf.org/doc/html/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. – Spomky-Labs Jan 25 '22 at 12:34
-4

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.

Khedron Wilk
  • 7
  • 2