Identity Providers — Types of Tokens in OpenID Connect and OAuth2 Contexts

Overview of Tokens (ID token, Access token, Refresh token) in OpenID Connect (OIDC) IdP.

TL;DR:

Tokens are vital in managing access and identity in the digital world. They serve as data representations of a user’s identity or provide access to specific resources.

• ID tokens used for authentication.
• Access tokens used for authorization.
• Refresh tokens used to get new access tokens.

ID Token (id_token)

ID token is the identity information about the user, a JWT, issued by an IdP to a client, that contains claims that you can use to identify users in your application.

• ID token used strictly for authentication. It proves that the user has been authenticated. ID tokens are meant to be read by the client to identify a user’s identity.
• ID token identifies who a user is, and is commonly used to display user account information or to make access control decisions in an application.
• ID token used right after delivery. ID token has a very short lifetime. Application often implements its own expiration policy. They are meant to be short-lived for security reasons. Usually valid for a few minutes.
• ID tokens may have additional information about the user/subject, such as their email address, given name, picture, and so on. You can use the claims in an ID token as you see fit.
• ID token is digitally signed by the issuer with its private key. This guarantees the origin of the token and ensures that it has not been tampered with.
• ID token can be verified by the intended recipient. When your application or API receives an ID token, it must validate the signature to prove that the token is authentic. Also, validate a few claims in the token to prove that it’s valid.
• ID token is encoded as a JSON Web Token (JWT), a standard format that allows your application to easily inspect its content.
• ID token is a result of Open ID Connect (Google, Facebook, Twitter, etc.) that is sent to your Client Application.
• ID tokens are signed, but they aren’t encrypted. May optionally be encrypted for confidentiality.

Typical ID token data:

• sub: Identity of the user, called subject.
• iss: Specifies the issuing authority.
• aud: Generated for a particular audience (e.g. client).
• iat: Issue time.
• exp: expiration time
• nonce: May contain a nonce.

Access Token (access_token)

Access token is used to provide access to APIs and resource servers, a JWT that contains claims that you can use to identify the granted permissions to your APIs.

• Access token used strictly for authorization. It allows the client to access a resource to perform specific actions.
• Access token provides information about who you are, what you wish to do, and whether are you authorized to do that.
• Access tokens are also called bearer tokens, which means that anyone in possession of the token can use it to access the resource without further identification.
• Authorization server grants an access token to a client with the appropriate scope (what a client can access) and the client uses it to access the resource.
• Access token usually has a short lifespan for improved security. IdP controls expiration policy. Usually valid for a few hours. It cannot be revoked, have to wait for this token to time out.
• When the access token expires, the user must authenticate again to get a new access token limiting the exposure of the fact that it’s a bearer token to gain access to resources.
• When your API receives an access token, it must validate the signature to prove that the token is authentic. Your API must also validate a few claims in the token to prove that it’s valid.
• Access token is not required to be in JWT format. It can be a string in any format, but usually formatted in JWT.
• Access token is a result of OAuth2.0 that is sent to your application.
• Access tokens are signed, but they aren’t encrypted.

Refresh Token (refresh_token)

Refresh tokens are used to acquire new ID tokens and access tokens.

• Refresh tokens provide your application with long-term access to resources on behalf of users without requiring interaction with those users.
• Typically, Refresh tokens are long-lived. Usually valid for a few hours or days.
• In response to Refresh token, get a new Identity Token, Access Token, and Refresh Token. It replaces the refresh token that you previously used in the request. This action helps guarantee that your refresh tokens remain valid for as long as possible.
• Refresh tokens can be invalidated at any moment for various reasons. This allows for long-lived sessions that can be killed if necessary.
• Refresh tokens are opaque to your application.

Typical usage steps:

1. User logs in and gets back an access token and a refresh token.
2. Application detects that the access token is expired.
3. Application uses the refresh token to obtain a new access token.
4. Repeat 2 and 3 until the refresh token expires.
5. After the refresh token expires, the user must authenticate again.

Session token

Session token used to maintain stateful interactions between the client and server.

CSRF token

CSRF token used to prevent a specific type of attack where a user is tricked into acting on a different website without their knowledge.

Summary

• ID tokens carry identity information encoded in the token itself, which must be a JWT.
• Access tokens are used to gain access to resources by using them as bearer tokens.
• Refresh tokens are used to get new access tokens.

View more from .NET Hub

• Clean Architecture with .NET and .NET Core
• Top .NET (ASP.NET Core) Open-Source Projects
• Most popular .NET Libraries every developer should know
• Introduction to Cloud Native Application Architecture
• Use MediatR in ASP.NET or ASP.NET Core
• Use FluentValidation in ASP.NET or ASP.NET Core

Happy Coding!!!