Simply a unique string that acts as a database key
Nothing to decode, extract or decrypt
JWT
purposefully filled with authorization and profile data
Access Token
Comes from OAuth 2.0 workflow
They are JWT
very sensitive
They are not used for authentication
The access token do not guarantee that the user is logged in
aud: the audience (destination) is the resource server where the protected resource reside
expiration based on use case:
read only, low risk data → long expiration time
read only, sensitive data → short expiration time
read and write, sensitive data → very short expiration time
Refresh Tokens
They are opaque
They are used exactly at one place: /token end point of our authorization server
The authorization server can take the refresh token, make sure it is still active and then issue a new access or refresh token
It is very dangerous token and should be protected, An attacker can use it to retrieve a new access token indefinitely. Only way to stop attacker is to revoke a refresh token
ID Token
Defined in OIDC, and comes from OIDC workflow
Always JWT
highly structured and strictly defined
proves that user has been authenticated
Not meant for Authorization, also, do not have any authorization info inside
They should not be sent to any API
aud: The audience (destination) is the application where the user is logged in.
The information from ID Token is used to show information about the user on the application.