How to differentiate JWT access token from refresh token used as Authorization header

Question

How can you determine if the JWT token used in Authorization: Bearer ... is an access token or a refresh token. In other words what prevents the user from using his JWT refresh token in the Authorization header instead of the acces token.

When I look at the payload of both the access token and the refresh token in this guide section https://github.com/starkandwayne/ultimate-guide-to-uaa/blob/master/docs/refresh-tokens.md#jwt-refresh-tokens I don't see any real way to identify which one is which.

Refresh token:

{
"jti": "3e53955fcff6429a8a187c4c37f1b592-r",
"sub": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"scope": [
    "openid",
    "airports.all"
],
"client_id": "airports",
"cid": "airports",
"user_id": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"origin": "uaa",
"grant_type": "password",
"user_name": "airports-all",
"rev_sig": "4c3b3810",
"iat": 1530739971,
"exp": 1533331970,
"iss": "https://192.168.50.6:8443/oauth/token",
"zid": "uaa",
"aud": [
    "openid",
    "airports"
]
}

Access token:

{
"jti": "fe39323464d74fb5a6fcb71d89f722c4",
"sub": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"scope": [
    "openid",
    "airports.all"
],
"client_id": "airports",
"cid": "airports",
"azp": "airports",
"user_id": "48a8d464-12dd-4b14-b7a0-96af58379ffb",
"origin": "uaa",
"grant_type": "password",
"user_name": "airports-all",
"email": "[email protected]",
"auth_time": 1530739970,
"rev_sig": "4c3b3810",
"iat": 1530739971,
"exp": 1530783171,
"iss": "https://192.168.50.6:8443/oauth/token",
"zid": "uaa",
"aud": [
    "openid",
    "airports"
]
}

What is the standard? Put a different scope?

Gary Archer Gary Archer · Accepted Answer · 2020-01-11T09:25:12

As in the link you've posted, the recommendation is to use opaque refresh tokens that are not JWTs, and you should use that configuration.

The client (usually a UI) should only ever send access tokens to the back end and any other type of token should be rejected. The correct configuration enforces this.

The back end's job is to validate the received JWT. A non standard setup as above could mean that this will work with a refresh token, but this is bad in 2 ways:

The API message credential has a very long lifetime and security risks are greater if a token is intercepted somehow
The solution is not portable and is likely to break for the client in future, or if you ever change providers

How to differentiate JWT access token from refresh token used as Authorization header

1 Answers