In authentication and authorization, a token is a digital object. It is an encrypted, machine-generated code and therefore inherently more secure than passwords. As a self-contained unit, a token contains all the information about the identity of the account making the request and what type of access it is authorized for.
Each token used in the authorization process is valid for only one specific user session. Protected by an algorithm, manipulated tokens can be identified and rejected by the server. In principle, a token has an expiration date. The shorter the maximum lifespan of a token, the more secure that token is considered to be. A longer lifespan is better for the user experience and for the economical operation of the server infrastructure. Therefore, a good compromise must always be found between a lifespan that is too short and one that is too long.
Which tokens are there?
The following are some of the token types used under OpenID Connect (OIDC), which is the standard authentication protocol based on OAuth2.0:
ID Token
An ID token is a JSON web token (JWT) that conforms to the OIDC specification. It contains data about how and when a user authenticated themselves. It can also contain data about the user, such as name, email, or phone number. And because an ID token is transparent, the ID token can be verified and used by an application. In addition, the identity information can be used to authenticate a user. ID tokens are typically valid for up to 1 hour (3,600 seconds), after which the client must request a new ID token. An ID token is signed by the issuing Identity Provider (IdP), which allows the client to verify that the token has not been tampered with and who issued it. The IdP issues this token to the user’s client (application, web application, etc.).
Access Token
An access token contains authorization information (user privileges and expiration dates), but usually no identity data, and provides access to specific user resources. In most cases, this is a JSON Web token (JWT) or provider-specific formats. Not only can the basic format be vendor-specific - in the case of JWT, the information it contains can vary widely in some cases. Clients can use these tokens to act “on behalf of users”. For example, when a client accesses an API with a token, the server behind it knows which user did it, and that the client is trusted for that action. In principle, the access token can be verified by any participant (client or server). In most cases (as with the ID token), the signature of the IdP is used for verification. However, it may also be necessary to call a special API endpoint of the IdP to verify this token. At Engity, we primarily use JWT for this purpose.
The lifespan of access tokens today usually ranges from 15 minutes to 1 day.
Refresh Token
When the user logs in to a protected resource, they will receive a refresh token in addition to the access token. When an access token expires, the Refresh Token can be used to request a new, valid access token. In general, a refresh token can only be used once, and each time a new refresh token is received with the new access token. A refresh token is also an OAuth2.0 construct and typically has a very long to unlimited validity. However, it can be revoked at any time due to session timeouts, changes in credentials, or other events.
The lifespan of a refresh token today typically ranges from 1 hour to 1 year, depending on the sensitivity of the information secured by that token.
Session Token
A session token (or session cookie or session ID in other contexts) is not an OIDC or OAuth2.0 standard. It contains an encrypted, unique string and is used as an identifier. The session token is stored locally in the user’s browser cache and is sent to the server with each request, verified, and if it matches, the request is processed. A session token also helps keep the session active as long as possible. For example, if the access and refresh token has expired but there is still a valid session token, the session token is used to perform a silent login. Only when the user actively logs out of the application is the session token destroyed on the client and/or server side and the user must log in again.
Authorization Code
Once a user has successfully authenticated, the OpenID Connect provider (IdP) sends an authorization code to the user’s browser. In the next step, this code is sent to the relying party application, and the browser receives an access token, refresh token and ID token in return.
The lifespan of an authorization code usually does not exceed five minutes.