Question

The accepted answer here as to why OAuth2 access tokens expire:

• Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token. (What does this mean? I take it to mean allow transmission without TLS? Anything else?).
• Large scale deployment don’t want to perform a database lookup every API call, so instead they issue self-encoded access token which can be verified by decryption. However, this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed.
• The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.

Assuming that we don’t support non-encrypted transmission of the access token takes care of the first bullet point.

Assuming that we are fine with doing a database lookup against a revokable, completely random access token takes care of the second one.

For mobile apps, client authentication cannot be stronger, because “the client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret.” (Google). That eliminates the third concern.

So what is the benefit of separating short-lived access tokens and long-lived refresh tokens in this scenario? Is it “okay” to just issue non-expiring access tokens and ignore the whole refresh token part?

Answer 1

The difference between a refresh token and a non-expiring access token in means of security is one additional call to the authorization server.

If an attacker gains access to your non-expiring access token, he can directly call your resource server and get confidential data as response.
Now if he steals your refresh token, he first has to call the authorization server and receive an access token in response. Then he can query the resource server for confidential data.

Each time an access token is requested from your authorization server using a refresh token, the OAuth 2 specification (at least the latest draft for now) requires the server to check the client identity and if it is bound to the token, if possible.

As the normal approach with a client secret does not work to definitly identify an installed application on an open platform, the platform running the application has to provide methods to do this. Google e.g. requires Android applications to be signed by the developer. When requesting credentials for an Android application using the Google API Console, you therefore have to specify the fingerprint of the certificate you used for signing the application and only get a client ID, but no secret in response. On issuing tokens, Google can then decide if the application was authorized by the developer to request tokens in his name.

If you definitly can’t verify the client identity, it is at least possible in some cases to recognize that a refresh token was stolen. The specification has an example for this:

When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.

For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.