4

From RFC 6749 (section 10.4):

The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.

I don't understand why this is necessary since when the client wants to obtain an access token using the refresh_token grant type, it MUST send a client ID and a secret key in the body of the request, otherwise the request is denied by the authorization server. Unauthorized party would have to somehow acquire the client ID and the secret key.

2

... since when the client wants to obtain an access token using the refresh_token grant type, it MUST send a client ID and a secret key in the body of the request...

According to RFC 6749 this statement is not entirely true. The refresh token is the only information a client needs to obtain a new access token.

However this is only the case for public clients as defined in section 2.1 of the specification. You could imagine the client id and the client secret as a sort of license to consume an API to provide certain services to your customer. But you need a special permission of every customer to consume their resources from the API. The access token is the representation of this permission. However you would not give your license to consume the API away to a customer. This would be the case in many browser and mobile device applications.

  • According to section 6 a client ID and secret are required - if I understand the section correctly, the client id and secret are encoded in the authorization header or sent in the body of the request as described in section 3.3. – Pavel Dedik Jun 22 '16 at 14:53
  • I reflected your remarks in my edit. I hope It's more clear now. I didn't had much time yesterday. – Noir Jun 23 '16 at 8:15
1

Refresh_tokens are optionally generated alongside access_tokens by the authorisation service. The access_token is usually short lived (by comparison) and is solely used to gain access to whatever resource is required. Once the Access_token has naturally expired, then the refresh_token is used with the authorisation server to gain another access_token.

Typically refresh_tokens have a much longer lifespan http://blog.cloud-elements.com/oauth-2-0-access-refresh-token-guide for example states that some refresh_tokens do not expire

This means that an attacker has a long time to guess the refresh token, and then use it to obtain access_tokens.

If an attacker also requires the client ID and the secret key, the refresh key is adding an additional layer of complexity to the attack, effectively raising the bar. If it were easily guessable then there would be no point in using it as it adds no additional protection, and indeed possibly gives the false impression of more security

  • But you still need client id and client secret to claim a new access_token from a refresh_token. So why is it so important that the refresh_token can't be guessed? I think that's what the op asks. – Smuuf Jun 22 '16 at 12:50
  • "If it were easily guessable then there would be no point in using it as it adds no additional protection" -- The point is to identify a resource owner, an entity granting access to a protected resource (how else would the authorization server know for which entity to generate a new access token?). – Pavel Dedik Jun 22 '16 at 15:04
  • yes, but it's optional, so if you do use it and it's easily guessable then, as I stated, it adds no additional protection. All security is about cost/benefit, and raising the bar to the point that the attacker has to spend more resources than the value of the target. It's up to you to determine what protections you think are worth the cost – Colin Cassidy Jun 22 '16 at 15:17
  • Yes, I certainly agree that it adds an additional protection. In my case, however, I don't want to use a random string as a refresh token. I want the client to be able to obtain new access token just by knowing an entity ID, which could be used as a refresh token and could be acquired in serveral different ways (refresh token can be obtained only at the begining of the authorization flow). In my case the refresh token could be guessed since it is just an autoincremented number. I see almost no security risks here as the client is required to authenticate with a client ID and secret. – Pavel Dedik Jun 22 '16 at 16:55
  • in your case, how easy is it for the client to change its ID and secret if they are disclosed? Where is this client ID and secret coming from that it's required by your oauth solution... Ultimately what problem are you trying to solve, as I'm not sure that the question you initially asked is actually the problem that you are trying to solve – Colin Cassidy Jun 23 '16 at 7:28
0

Requirement of a client secret implies that the client is trusted by the authorization server, and typically only server-side services can be trusted by an authorization server.

Generally speaking, you don't want potentially untrustworthy clients like Mobile devices or Web browser to possess refresh tokens. This is why OAuth 2 implicit flow does not support refresh tokens.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.