5

It seems I don't quite understand the idea behind the refresh token yet.

Assuming that a short living access token is used. This token might get stolen, allowing the attacker to access the ressource until it experies (maybe 3600 seconds).

But what if he manages to steal the refresh token as well (shouldn't be more difficult as it is not more protected than the access token, right?)? Wont he be able to simply get a new access token with it since no authentication is required for refreshing the access token when someone posesses a refresh token?

2

TL;DR: Yes refresh tokens are bearer token and so should be protected.

Refresh tokens are powerful because in general they are:

  • long term: meaning that they have long expiration times
  • privileged capability: meaning that they allow the bearer to renew their access token.

Refresh tokens are also bearer tokens, which means the service consuming the token will give access to the bearer of the token -- no questions asked. This is similar to access tokens.

So making sure bearer tokens are protected and stored securely is very important. The more critical a token, the better it should be protected.

As an example in OAuth2, implicit flow which is generally used with mobile apps, the client side app has a short lived access token. They are also generally not given a refresh token. Since a client side app can be easily compromised and any data/tokens be compromised, its bearer tokens have limited privilege and lifetime.

In contrast, in OAuth2 authorization code flow which is generally used with server side apps, the server app is given a longer lived access token or/and a refresh token. This is because it is assumed that server side is more trusted and less likely for it to be compromised. Having said that, server side tokens should still be stored securely given their usage pattern.

To summarize, when deciding what kind of tokens you need, check: - trust level of your client and the flow most appropriate for that trust level - protect your tokens!

  • Can you clarify: you mentioned that Refresh Token is also a bearer token, however tools.ietf.org/html/rfc6749#section-6 says "the refresh token is bound to the client to which it was issued. 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" - so you must have client id and client secret in order to authorize, so that wouldn't purely rely on the the bearer alone, not? – Mathias Conradt Jun 17 at 6:53
0

You are right, this is why refresh token should be stored securely. Maybe encrypting it inside a cookie with the secure flag enabled, so it is only transferred over HTTPS.

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.