Entra ID Tokens and Where to Find Them

Introduction

In cloud environments, tokens are the backbone of secure authentication and authorization. They allow users to access resources, applications, and services without repeatedly entering credentials. If you're managing or testing applications in the Azure ecosystem, you're likely familiar with Entra ID tokens (formerly Azure Active Directory). But not all tokens are created equal, and understanding the differences between Access Tokens, Refresh Tokens, and ID Tokens is crucial for maintaining security and smooth user experience.

Let’s break down the different types of tokens, their lifespans, and how they work behind the scenes.

Bearer? SAML? Tokens that are basically security's middle child

In Entra ID, tokens vary by purpose and protocol, primarily following OAuth 2.0, OIDC (OpenID Connect), and SAML. Not all tokens strictly adhere to these protocols, Microsoft’s implementation has its own nuances that may affect security considerations. Here’s an overview of the major token types:

Bearer Tokens

Bearer tokens grant access based on possession alone—anyone holding the token can use it without additional credentials, making them especially valuable targets if stolen. In Entra ID, three tokens function as bearer tokens:

• ID Token - Used for authentication to verify a user’s identity; part of OIDC protocol.

• Access Token - Grants permissions to resources or APIs per OAuth 2.0.

• Refresh Token - Allows session continuation by renewing access tokens.

SAML Tokens

Azure Entra ID also issues SAML tokens in federated and legacy environments for SAML-based single sign-on (SSO). Unlike bearer tokens, SAML tokens follow XML-based SAML 2.0 protocol, providing authentication across multiple applications but with stricter access controls.

• Purpose: SSO, allowing a user to access multiple applications with one login.

• Security Note: SAML tokens enable impersonation if intercepted but are generally less exploitable than bearer tokens without a Golden SAML attack (an attack allowing forged SAML tokens).

Access, Refresh, and ID Tokens

In Entra ID, there are three core types of tokens, each serving a unique role:

• Access Tokens: These temporary tokens grant access to specific resources for a limited time.

• Refresh Tokens: Long-lived tokens that allow seamless renewal of access tokens without requiring user re-authentication.

• ID Tokens: Tokens that verify a user's identity but don’t grant access to any resources on their own.

With all that being said, let’s dive a little deeper into each token type.. or at least try to.

The "Workhorse" of Authentication

Access Tokens are the "doers" in the token family. They provide authorization to access specific resources like APIs or services. Access Tokens are short-lived, with a variable default lifetime between 60-90 minutes (averaging around 75 minutes). This variation, assigned by the Microsoft identity platform, makes token expiration less predictable and adds a subtle layer of security by reducing the chances of token reuse if compromised.

Access tokens are JWTs (JSON Web Tokens), which means they carry vital information like:

• aud (Audience): The recipient of the token (usually an API or service).

• exp (Expiration): The time when the token will expire.

• scp (Scopes): The permissions granted by the token (the actions it allows the user to perform).

Why Short-Lived Tokens?

Access tokens are short-lived by design to reduce exposure to risks. If an attacker steals an access token, they only have a limited time to exploit it before it expires. This short lifespan, combined with variable expiration, makes access tokens essential for minimizing replay attacks or misuse in compromised sessions.

Below is a simplified example of what the payload section of an Entra ID access token might look like when decoded. This snippet is a representation of some of the common claims you’d typically see in a real access token issued by Azure Entra ID

{
  "aud": "https://graph.microsoft.com",

  "exp": 1633029000,

  "scp": "User.Read"
}

Important Note on Token Lifetimes

Entra ID now uses adaptive token lifetimes, meaning tokens can automatically adjust their lifespan based on risk. While the default is still 1 hour, Conditional Access Policies can extend or reduce the token's lifespan depending on the user's behavior or environment (for example, issuing a longer token for trusted devices).

The Session Keeper

While access tokens expire quickly, Refresh Tokens are the unsung heroes that allow for seamless, long-term access. They enable applications to obtain new access tokens without requiring the user to log in again. Refresh Tokens are long-lived (valid up to 90 days) and use a sliding expiration model, meaning the token’s lifespan is extended with each use, provided the user is active.

How Do Refresh Tokens Work?

When an access token expires, the application sends the refresh token to Azure’s /token endpoint to get a new access token and a new refresh token. This process happens behind the scenes, so the user doesn’t have to re-authenticate frequently.

A little thing to remember: If a refresh token is compromised, it can be used to issue new access tokens, making it an extremely valuable target for attackers. That’s why refresh token rotation is crucial, each time a refresh token is used, it’s replaced with a new one, minimizing the risk of token reuse.

Example request using a Refresh Token:

The Identity Card

ID Tokens serve a different purpose than Access Tokens. They don’t grant access to resources, rather, they provide verified information about the authenticated user. Typically issued after successful authentication, ID Tokens are essential for confirming a user's identity in Single Sign-On (SSO) and OpenID Connect (OIDC) scenarios.

A typical ID token contains numerous claims, each serving a specific function. Here’s an example of a complete ID token payload taken from Microsoft's official documentation:

Key Claims Explained​

ver: The token version (e.g., "2.0").

iss (Issuer): The identity provider issuing the token, such as https://login.microsoftonline.com/{tenant_id}/v2.0

sub (Subject): A unique identifier for the user across all applications within a tenant.

aud (Audience): The application intended to receive and process the token.

exp (Expiration): The token’s expiration time.

iat (Issued At): The timestamp when the token was issued.

nbf (Not Before): Indicates the earliest time the token is valid.

name: The user’s full name.

preferred_username: The primary username or email associated with the user.

oid (Object ID): Unique identifier for the user within the Azure AD tenant.

tid (Tenant ID): Identifier for the user’s tenant.

nonce: Used to mitigate replay attacks, created by the application requesting the token.

aio: Microsoft-internal claim, used for monitoring and tracking.

rh: Reference handle for managing refresh tokens.

ipaddr: The IP address from which the user authenticated.

roles: User roles for access control.

email: The user’s email address.

family_name and given_name: User’s last name and first name, respectively.

unique_name: Similar to preferred_username, often used for display.

Validation of ID Tokens:

Applications validate ID tokens by verifying the token’s digital signature against Entra ID’s JSON Web Key Set (JWKS). This verification ensures the token’s integrity and authenticity. Additionally, applications should check the aud (audience) claim to confirm the token is intended for them, and the exp (expiration) claim to ensure it’s still valid.

SSO Across Devices

A Primary Refresh Token (PRT) is a specialized refresh token used in Azure AD joined and hybrid joined devices to maintain single sign-on (SSO) across multiple applications and devices. PRTs allow users to stay authenticated across apps without re-entering credentials.

PRT Validity and Security:

PRTs are valid for 14 days and can be continuously refreshed as long as the user remains active and compliant with Azure security policies. This makes PRTs ideal for device-based authentication, where users expect persistent access across apps on their Azure AD-managed devices.

Important Security Note: The PRT is tied to the device’s security posture—meaning it can only be used if the device remains compliant with Conditional Access policies. This tight coupling with the device adds an additional layer of security to the token.

TLDR

Imagine token management in Entra ID as a secure building with different types of access keycards:

• Guest Keycard - Access Tokens (1 Hour): Like a temporary guest keycard, Access Tokens grant short term access to specific rooms or areas. These tokens are valid only briefly and need frequent renewal, minimizing risks if lost.

• Resident Keycard - Refresh Tokens (90 Days): Refresh Tokens act like resident keycards, allowing longer access to multiple areas within the building. They extend access seamlessly for active users, much like residents re-entering without re-verification.

• Master Keycard - Primary Refresh Token (PRT) (14 Days): The PRT is like a master keycard held by authorized staff, providing broad access across multiple areas and devices. This keycard is protected by additional security measures, ensuring it can only be used on compliant and authorized devices.

A couple of things to consider and Best Practices

I. Token Replay Attacks

To mitigate the risk of token replay attacks, ensure that access tokens are short lived and frequently refreshed. Azure’s adaptive token lifetimes also help limit the attack window by issuing tokens based on the risk level of each session.

​​

II. Refresh Token Theft

Refresh tokens are high value targets. If compromised, they can be used to generate new access tokens indefinitely. To minimize this risk:

• Use Multi-Factor Authentication (MFA) for all users.

• Enable Conditional Access Policies to verify the context of token requests (e.g., blocking token issuance from suspicious locations).

• Implement refresh token rotation, ensuring that each refresh token is replaced after use.

​​

III. Token Binding

Microsoft supports token binding to defend against replay attacks. Token binding ensures that tokens are tied to a specific TLS session or device, making them unusable if intercepted by an attacker.

IV. Conditional Access and Token Security

Conditional Access Policies play a major role in token issuance and lifespan. These policies evaluate the risk associated with each sign-in or token request and adjust security accordingly. For example, high risk sign-ins may require MFA or device compliance before tokens are issued.

Conclusion and thoughts

Tokens are the keys to your kingdom, and understanding how each type of token works is essential for keeping your environment secure.

• Use short-lived access tokens to minimize exposure.

• Rotate refresh tokens regularly, and monitor for suspicious activity.

• Implement Conditional Access Policies to enforce real time risk assessments.

• Don’t forget token binding for an extra layer of protection.

Thanks for reading!