1

I'm working to implement a OAuth 2.0 server, and while reading the RFC6749 specification I realized that section 6 on Page 47 regarding "Refreshing an Access Token". Explains that we need to just use the Refresh Token that we have to get a new Token.

But for example, in addition to the Refresh Token, Google require the User ID and the Secret to do so.

This confuses me, because on one hand we have Google that is processing high volume of requests every day, and we have a specification written probably with a smaller scope in mind.

Is it good to send the Secret every hour with the Refresh Token?

Personally I believe no: because the User ID and Secret should be used only to go over the whole OAuth 2.0 process.

Basically

  1. You use the token on each request to prove that you are who you are.
  2. Refresh Token get used only once an hour (and potentially changed at each refresh)
  3. Secret and User ID go to the internet as rarely as possible. Only when option 1 and 2 get compromised.

I personally believe that sending the Secret with the Refresh token is less secure. But maybe I'm missing something.

If you have another point of view, please share it :)

1

Actually, if you read on, it also says

The authorization server MUST:

o require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),

o authenticate the client if client authentication is included and ensure that the refresh token was issued to the authenticated client, and

o validate the refresh token.

Which means quite that: Pass your client ID and secret with the refresh token request.

The specification is not very explicit in this regards, but says that you have prove who you are (or which application you are) in order to be able to do a refresh. Note that it's stated "confidential clients", which means that this is primarily intended to happen server side.

So, in addition to just passing the refresh token, you also have to pass your client authentication into token endpoint, which means that an attacker needs to get hold on multiple values to be able to use a refresh token he has gotten his hands on. This implies that you should possibly also store these things in separate places, and just assemble the needed data when you need to refresh your token.

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.