Search code examples
oauth-2.0google-oauth

Should I send the Secret with the Refresh Token in OAuth 2.0

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 :)

Solution

  • I might be missing something, but what Google requires and what's also specified by OAuth2 is that when refreshing a token from a confidential client application the client must authenticate itself.

    The most common type of credentials being used for confidential clients are a client identifier alongside a client secret. This information is issued to a client application and is unrelated to the end-user.

    By requiring client authentication the authorization server can be sure the request comes from a specific client and adjust its response accordingly. For example, an authorization server can decide that certain permissions - scopes - can only be requested from confidential clients.

    The argument around reducing the number of times the client secret needs to be sent over the wire is a non-issue. OAuth2 mandates that the communication happens over TLS and if you have issues with sending the secret then you would also have issues with sending bearer access tokens.

    In conclusion, although sometimes doing things exactly according to spec without questioning the overall context might lead to vulnerabilities:

    ... some libraries treated tokens signed with the none algorithm as a valid token with a verified signature. The result? Anyone can create their own "signed" tokens with whatever payload they want, allowing arbitrary account access on some systems.

    (source: Critical vulnerabilities in JSON Web Token libraries)

    Some libraries treated the none algorithm according to spec, but ignored the usage context; if the developer passed a key to verify a signature it most likely did not want to treat unsigned tokens as valid.

    However, passing the secret on the refresh token request is not one of these situations so don't worry about it.