Understanding Tokens in Entra ID:
A Comprehensive Guide

By Lina Lau, September 18, 2024

12 min read

When you hear “tokens” in the world of Entra ID, what does it mean? There are different types of tokens with different utilities. Not all tokens are created equal either; there are more attractive tokens for an attacker to steal causing a world of confusion and pain for blue and red teamers.

This blog aims to demystify the primary differences between the most common types of tokens you may encounter and the attacks they are susceptible to. We will cover the following topics:

Token Hierarchy – What token to steal?

Different Types of Tokens

ID tokens

Access Tokens

Refresh Tokens

Family of Refresh Tokens

Primary Refresh tokens

If you're curious to learn more about Entra ID, check out our training Attacking and Defending Azure and M365 offered both on-demand and in-person.

Token Hierachy: What Token to Steal?

What token should you steal as an attacker? This depends on the attacker’s actions on objectives and the utility (usage) of the token. The token hierarchy list below is placed in order of attractiveness to an attacker based on access duration, bypasses, and lateral movement/privilege escalation opportunities. The blog post expands further into each type of token but this section is the TL;DR for the entire blog post.

Most organisations rely on Conditional Access policies as one of their primary protection methods against cloud attacks. However, if an attacker steals a Primary Refresh Token – conditional access policies are not evaluated or applied to the issued PRT. This means the conditional access policies are not the most effective mitigation technique for PRT (there are others, but we won’t go into mitigations in this blog post).

The second best (or tying for first place) token to steal are tokens that grant 90-day access and allow opportunities for an attacker to perform lateral movement and privilege escalation. Naturally this would be the undocumented Family of Refresh Tokens (FRT). These group of refresh tokens allow an attacker the ability to mint access tokens for other applications within the “family”.

The third would be a refresh token that grants an attacker persistent access to a specific resource for up to 90 days. The final contenders would be an access token or a SAML token with a lifetime of 1 hour each. The ranking for a SAML token would be higher if a Golden SAML attack has taken place.

Different Types of Tokens

Tokens grant access to one or more resources in the cloud. There are several different “types” of tokens that exist – for example, access tokens and SAML tokens. These different types of tokens supposed to follow varying protocol references such as the OAuth 2.0, ODIC and SAML. However, Microsoft does not strictly adhere to these guidelines as outlined by this fantastic writeup from Secureworks where the OAuth 2.0 standard isn’t abided by.

In the world of tokens abiding by OAuth 2.0, there is a concept of a “bearer token”. You may see or be familiar with this when you perform a “pass the token” attack and paste your token in the request after the word “bearer”. Bearer tokens are a security token where “any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can”. This naturally leads to the assumption that if stolen, bearer tokens can be maliciously abused by an attacker to perform their actions on objectives. This may be a concept you’re familiar with if you’ve stolen a token and noted that they start with “eyJ” or “0.AU”. Bearer tokens typically are represented by a JSON Web Token (JWT) which can be decoded using something like “jwt.io”.

Below is an image of a token being “decoded” – and as you can see this bearer token contains a refresh token within it.

Now, the next logical question would be what types of tokens can be a bearer token? The answer to this question would be 3 – there are three different types of bearer tokens and they are:

ID Token Lifetime: 1 hour
Used for authentication and contains information about the resources, owner, UPN etc

Access Token Lifetime: 1 hour
Used for authorization and are credentials that are used to access an application/resource

Refresh Token Lifetime: 90 days
Used to obtain new tokens that have expired.

Now, aside from bearer tokens; Microsoft also issue SAML tokens to facilitate single sign-on (SSO). These tokens are valid for 1 hour and can be used by an attacker to impersonate a user’s access to multiple different resources. In the absence of a Golden SAML attack (granting the attacker the ability to forge multiple SAML tokens), these tokens rank lower on our hierarchy list.

ID Tokens

These tokens are valid for 1 hour and prove authentication (that a user has authenticated to a resource/application). The token contains information including verification details around who the user is. The primary difference between an ID token and an access token is that the ID token itself “should” not be used to authorization purposes (which is what an access token is used for). Now with all things, “should not be used” does not always mean “cannot be used”.

The image below is a decoded ID token, and as you can see it contains details around the user, the IP address, and further details around the user verification.

Microsoft documentation on ID Tokens: https://learn.microsoft.com/en-us/entra/identity-platform/id-tokens

Access Tokens

Valid for 1 hour, these tokens grant access to resources and are used for authorization. These tokens embed information around who the user is and what specific resource the access is intended for. As you can see from the decoded access token below – the token has the scope graph.microsoft.com via the client (application) Microsoft Office.

Access tokens can be stolen and “passed” to maliciously access the scope and application on behalf of the victim user.

Refresh Tokens (An Attacker’s Buffet)

Refresh tokens are a type of bearer token that can be redeemed by an application to fetch a new set of “bearer tokens”. Since access tokens have a lifetime of 1 hour, this is where the utility of a refresh token comes in for the attacker. These tokens can be used continually within the lifetime of 90 days to obtain new access tokens. Given this power, refresh tokens are typically the primary target for attackers as it grants them up to 90 days of continual access to a specific resource / application.

When decoding the bearer token, this is what a refresh token will look like:

Here is where the nuance comes in, there are different TYPES of refresh tokens that exist (refresh tokens, Primary Refresh Tokens (PRT), and Family of Refresh Tokens (FRT)). With regards to these different types of refresh tokens, there are two key distinctions that they each fall into:

Type 1: Refresh token that allows an attacker to obtain an access token to the SAME resource only

Type 2: Refresh tokens that allow an attacker to obtain access tokens for OTHER resources.

Family of Refresh Tokens (FRT)

There is a second type of refresh token known as Family Refresh Tokens (FRT) that are also valid for 90 days. This research was publicised by Secureworks in this write-up about Family of Client IDs. This “FRT” is undocumented by Microsoft. These tokens can be used by an attacker to mint tokens to ALL applications within “the family”. Now this “family” is undocumented by Microsoft, but Secureworks keeps a non-exhaustive list of what these are here.

This implementation of FRTs by Microsoft contradicts the OAuth 2.0 standard. As per the OAuth2.0 safeguards, bearer tokens are supposed to only be used to obtain tokens with identical or narrower scope and for the same client (application) it’s issued for. This is not the case with FRTs.

What this means in layman terms is, if an attacker steals a refresh token for any application within this “family” – they can mint tokens to ALL the applications inside this family (allowing lateral movement). In terms of attacker hierarchy, the implication here is: depending on your attacker objective, aim to get a FRT over a typical refresh token as this allows you room for lateral movement and privilege escalation.

Primary Refresh Tokens

Valid for 14 days, these refresh tokens are used for single sign-in (SSO) across applications used on the device and contain two additional details embedded in them:

Device ID: This field identifies the device where the PRT resides on

Session Key: Acts as a proof of possession when the PRT obtains tokens for other applications

Similar to FRT, these tokens can be used to access multiple different resources (not abiding by the OAuth 2.0 standard). As per Microsoft documentation, Conditional Access policies are not evaluated when PRTs are issued. Therefore, if an attacker steals a PRT, it will automatically satisfy device-based conditional access policies.

We tested this in our tenant and found that even when conditional access policies are applied which restrict geolocations, we were still able to successful perform “Pass the PRT” and bypass these conditional access policies.