Understanding OpenID Connect and OAuth 2.0 Tokens

Emmanuel Gautier · January 19, 2025

OpenID Connect enabling applications to obtain user information from a trusted identity provider (IdP). Central to its functionality are several types of tokens, each serving distinct purposes. In this article, we’ll explore the different tokens, their formats, and their appropriate use cases.

Tokens in OpenID Connect

OpenID Connect primarily deals with three types of tokens:

ID Token
Access Token
Refresh Token

Each token has a specific role in the authentication and authorization process. Let’s dive into the details of each.

Summary of OpenID Connect and OAuth 2.0 Tokens Use Cases

Token Type	Format	Purpose	Used By
Access Token	JWT or Opaque	Authorize access to resources	Resource Server (API)
ID Token	JWT	User authentication	Client Application
Refresh Token	Opaque	Obtain new access tokens	Authorization server

Access Token

Purpose

The access token is used to authorize access to protected resources, such as APIs. It serves as proof that the user has been granted permission to access a particular resource.

Format

The format of the access token can vary depending on the implementation:

Opaque Tokens: These are non-readable by clients and require validation by the resource server.
JWT: Some implementations use a JWT format, which is readable and contains claims about the scope of access, user identity, and expiration details.

If you want to make the right choice between JWT and Opaque Tokens in the context of Machine To Machine, you can check our blog post on JWT vs Opaque Tokens for M2M.

When to Use

Access tokens are intended for use by resource servers (APIs). A client application includes the access token in the Authorization header of an API request, typically as a Bearer token:

GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer <access_token>

The resource server validates the token to ensure it is active and authorized for the requested action.

How to verify the Access Token

When the client application sends an access token to the resource server, the server must validate the token. The validation process can be done in several ways:

Introspection: The resource server sends a request to the token introspection endpoint to validate the token.
Local Validation: The resource server validates the token locally using the public key of the IdP when the token format is JWT.
User Info Endpoint: The resource server can use the user info endpoint to retrieve additional information about the user associated with the token.

ID Token

Purpose

The ID token is the centerpiece of OIDC. It is a JSON Web Token (JWT) that contains claims about the user’s authentication session, such as their identity and how they were authenticated. This token is used by the client application to verify the user's identity.

Format

The ID token is always a JWT, which consists of three parts:

Header: Contains metadata about the token, such as the signing algorithm (e.g., RS256).
Payload: Contains claims about the user and the authentication event, including:
- sub: A unique identifier for the user.
- iss: The issuer of the token.
- aud: The audience for whom the token is intended.
- iat, exp: Timestamps for when the token was issued and when it expires.
- nonce: A value used to associate the token with the original authentication request, preventing replay attacks.
Signature: Ensures the token's integrity and authenticity, signed by the IdP using a private key.

ID Token can contain additional claims, such as auth_time (authentication time) or acr (authentication context class reference). If you want to know more about the standard claims in the ID token, you can check our blog post on OpenId Connect Standard Claims.

When to Use

The ID token is used exclusively for authentication purposes. It should not be used to access APIs or resources. For instance, a web application can use the ID token to display the user's profile information or establish a session.

Most of the time, the Access Token has enough information to identify the user. However, the ID Token is useful when the client application needs to verify the user's identity or obtain additional information about the authentication event (e.g., the authentication method used). When Access Token format is not JWT, the ID Token can be easier to read and parse, as it is always a JWT.

A practical example of using the ID token is the step-up authentication process. If you want to know more about how to implement step-up authentication with OpenID Connect, you can check our blog post on Step-Up Authentication with OpenID Connect.

How to verify the ID Token

To verify the ID token, the application must verify it as a JWT, validate the signature, and check the claims. The application should also ensure that the iss claim matches the expected IdP, the aud claim matches the client ID or the expected value defined by the provider, and the exp claim has not expired.

If you want to know more about how to verify a JWT, you can check our blog post on how to verify a JWT.

Refresh Token

Purpose

The refresh token is used to obtain new access tokens without requiring the user to reauthenticate. This is particularly useful for maintaining long-lived sessions.

Format

Refresh tokens are usually opaque strings and are not intended to be parsed or inspected by the client. Unlike ID and access tokens, they are not JWTs.

When to Use

Refresh tokens are used in the background to renew access tokens. For example:

The user logs in, and the client receives an access token and a refresh token.
When the access token expires, the client sends the refresh token to the IdP to request a new access token.

Note: Refresh tokens should be stored securely. If compromised, they could allow an attacker to gain new access tokens.

Token Lifetimes and Security Considerations

Token Lifetimes

Each token has a specific lifetime, which is defined by the IdP. The lifetime of the tokens can vary depending on the security requirements of the application.

Access Token: Typically has a short lifetime to minimize exposure if leaked (e.g., 5-15 minutes).
ID Token: Typically short-lived (minutes to hours), as it is used only during the authentication process.
Refresh Token: Has a longer lifetime than access tokens (e.g., days to months) to maintain long-lived sessions but should be revocable by the provider.

When implementing OpenID Connect, consider the following security best practices:

Secure Storage: Store tokens securely, such as in HTTP-only cookies or secure storage mechanisms.
Validate Tokens: Ensure that tokens are validated for authenticity and integrity.
Use HTTPS: Always transmit tokens over HTTPS to prevent interception.
Rotate Keys: Regularly rotate cryptographic keys used to sign tokens.
Minimize Scopes: Request only the necessary scopes to limit token capabilities.