The Microsoft Entra Sign-in logs contain all sign-ins to an Azure tenant, including sign-ins to internal applications and resources utilising Microsoft Entra Authentication. When a user authenticates against Microsoft Entra, they are issued a security token, these security tokens are what allows the client application to access protected resources across your Azure tenant.
In this article, I am going to focus on the appearance of Primary Refresh Tokens in the Entra ID sign-in logs. Still, for that, it is important to understand the different types of security tokens that Microsoft Entra issues.
There are four core types of security tokens which are issued to clients to access protected resources, these are; Access tokens, Refresh tokens, ID tokens and Primary refresh tokens.
What are Access Tokens?
An Access token is issued during the OAuth 2.0 flow (OAuth 2.0 is the industry standard for authorisation). This flow can happen in a variety of different ways: (I have excluded some flows which are not entirely relevant today).
- Auth code grant – this flow is what you may experience the most, by being presented with an interactive login window to enter your username, and password and complete your MFA challenge.
- Client credentials grant – this flow permits a web service to use its credentials to authenticate to another service. For example, it is utilising a client secret or certificate to access Microsoft Graph.
- Device code flow – this flow is mainly used for IoT devices where there is no interactive login prompt option. A code will be presented on the device, which is entered into the web browser of another device, to facilitate the login on the IoT device.
- On-Behalf-Of flow – this flow first requires the user to log in to a service to obtain a user security token, the service then uses the OBO flow to send this token downstream to access another service (such as Microsoft Graph) as the signed-in user.
What are Refresh Tokens?
When the client acquires an Access token to access a resource, the client is also issued a Refresh token. This Refresh token is then used to obtain further Access and Refresh tokens when the initial Access token expires. In this case, the Refresh token has a longer lifetime than the Access token, usually 90 days for most scenarios and isn’t tied to any particular resource, which means it could be used to obtain access tokens for other resources in your environment also. To summarise the flow:
- A user signs into Application1 and is issued an Access token (60-minute lifetime) and a Refresh token (90-day lifetime). (the user’s access to the said resource is defined within the access token)
- After 60 minutes the client uses its Refresh token to automatically obtain a new Access token to validate the user’s access to the resource and a new Refresh token
- The client’s access to the resource persists permanently.
In the event the user does not access the application for 90 days, the tokens will never renewed and the user will be asked to enter their credentials again.
What are ID Tokens?
Unlike Access or Refresh tokens, ID tokens are not directly used for authorisation. Instead, ID tokens contain claims that include information about the user and are often used for the user experience of an application or even as a unique identifier for a user in an application database. ID tokens are only valid for 1 hour and are bound to the combination of user and client.
An ID token often includes information such as:
- Given name
- Family name
- First name
- Email address
While an ID token will also contain the roles assigned to the user, it will not detail the scopes requested by the application, for example, in Microsoft Graph.
What are Primary Refresh Tokens?
Primary refresh tokens (PRTs) are designed specifically to provide SSO (single sign-on) across Microsoft applications on Windows 10 or newer devices or mobile devices running iOS and Android. They have a shorter lifetime than refresh tokens (14 days), but they are constantly renewed as long as the user uses their device, providing persistent authorisation.
Fundamentally a PRT is a Microsoft-invented token containing both the settings of an Access token and Refresh tokens. Instead of being bound to a single client, they can re-used across most Microsoft applications on the device. Other security tokens for Microsoft Entra ID are based on the OAuth 2.0 authorisation protocol.
As PRTs are device-bound, they are only issued to devices that are registered to Microsoft Entra ID in any of the following configurations:
- Microsoft Entra Registered
- Microsoft Entra Hybrid Joined
- Microsoft Entra Joined
Can Primary Refresh Tokens be stolen?
Yes, PRTs can be stolen, but only in certain scenarios. In most cases, an attacker can only steal a PRT from devices with their TPM chips disabled. This is because if your device has a functioning TPM chip when it is registered in Microsoft Entra, the PRT will be protected by the TPM chip, making it significantly harder to steal. TPM is a requirement of Windows 11 and will be enabled by default. For Windows 10 devices, TPM is not required, and the likelihood of a PRT not being protected by the TPM is higher.
Thomas Naunheim has published a very detailed post on the replay of Primary Refresh tokens here. It goes into detail on the scenarios where it could occur and any mitigation you can make.
PRTs are highly sensitive and as such, if an attacker gains code execution on a device that doesn’t have a TPM, regardless of the Conditional Access policies in place, they will be able to steal and reuse the PRT as needed. In this instance, you should disable the device object in Microsoft Entra and re-provision the device to be safe. For further reading to PRT security, consider reading this post by Dirk-jan Mollema.
Finding the incoming token type in the Microsoft Entra Sign-in logs
One of the great things about Microsoft Entra is the level of detail you can obtain about interactive or non-interactive sign-ins in the Sign-in logs. In the case of Primary Refresh Tokens, the sign-in logs can help you determine if a PRT was used to re-authorise and authenticate a login to Microsoft Entra.
To access the sign-in logs from the Microsoft Entra portal:
- Log in to https://entra.microsoft.com/
- Expand Protection
- Select Conditional Access > Sign-in logs
- Choose User sign-ing (non-interactive) and select a log from the list.
Scroll down to the bottom of the log and you will see the Incoming token type.
For programmatic access, you can filter the Entra ID sign-in logs using Microsoft Graph PowerShell to only return logs with the incoming token type as Primary refresh token.
For guidance on installing the Microsoft Graph PowerShell modules, see this article https://ourcloudnetwork.com/how-to-install-the-microsoft-graph-powershell-sdk/
Connect-MgGraph -Scope AuditLog.Read.All
Get-MgBetaAuditLogSignIn -Filter "incomingTokenType eq 'primaryRefreshToken'" This will return the last 30 days’ worth of logs to your PowerShell session. Depending on the size of your environment, this may take some time. You should combine the above filter with date and user-based filters to refine your results. Review this article to further filter the sign-in logs with PowerShell: How to Manage Microsoft Entra sign-in logs with PowerShell
Token type inconsistencies in the sign-in logs
I recently noticed in the sign-in logs that when an expected refresh token is used to obtain an access token, it is instead reported as the incoming token type being a Primary Refresh Token. This behaviour is correct and has since been reported to the Microsoft Engineer team, who assure me a fix will soon be released.
In this instance, if a device has not been registered with Microsoft Entra, when you log in to an Office application and select ‘This app only’ when presented with the option to enable single sign-0n, Entra still reports being issued a PRT instead of an access token.
You can check this behaviour by opening the non-interactive sign-in logs like before and searching for logs which contain the incoming token type as Primary refresh token and no Device ID.
While this issue does not need to be constantly monitored, you can quickly verify if you are impacted using the Microsoft Graph Explorer tool and this filter query:
https://graph.microsoft.com/beta/auditLogs/signIns?$filter=incomingTokenType eq ‘primaryRefreshToken’ and deviceDetail/deviceId eq ”&?$select=deviceDetail
