Table of Contents
Some already know what a Primary Refresh Token (PRT) is, but I want to remind you all if you forgot or just getting to know PRT for the first time.
After I read a GitHub post(link is below) which explains Primary Refresh Token attacks on a Azure AD Joined device I thought it was time to spread some light on this magic that happens on your device.
Some would say that is reliable on only the identity but you are wrong.
Primary Refresh Token is a combination of both identity and device, the device is your most important piece of protection when we talk about securing our identities unless you are some kind of magic man.
Primary Refresh token
Primary Refresh Token (PRT) is a Microsoft-invented token that contains both Access tokens and Refresh tokens, but unlike traditional OAuth 2.0 tokens, it can be reused across all applications. Pure OAuth 2.0 only grants access to a single application, so there is no SSO.
- Gives OAuth 2.0 tokens extra security with device id(device key) and session key(transport key and Proof-of-Possession (POP))
- Able to apply challenges like MFA claim and much more to satisfy Conditional Access
- Possible to be manipulated with Conditional Access Sign-In Frequency (SIF)
- Valid for 14 days default and is continuously renewed so long as the user actively uses the device.
A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10 or newer, Windows Server 2016 and later versions, iOS, and Android devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices.
Let me describe "dsregcmd /status," which enables you to troubleshoot your device quickly if PRT is missing on Windows.
- AzureADJoined, if our device identity is Azure AD Join.
- AzureAdPrt, is the Primary Refresh token (contains, challenges(claims), deviceid, and Refresh token which will give us access to our Access token)
- EnterprisePrt, if you are using ADFS (federated authentication)
- DeviceId, will tell us our deviceid which our PRT is associated with.
- TPM protected, will indicate if our device has TPM enabled which secure our Refresh token (+private device key and transport key)
A Device key (dkpub/dkpriv) and a Transport key (tkpub/tkpriv) are generated when a device is added to Azure Active Directory.
- tkpriv and tkpriv are protected within our TPM chip locally
- dkpub and tkpub are sent to Azure AD for validation. When we request a PRT, our device and Azure will determine if we are authorized to receive one(PRT).
Remember that PRT is Modern authentication and is build on upen standards like (SAML, OAuth 2.0 and ODIC). We are focusing on OAuth 2.0
OAuth 2.0 is not an API or a service: it’s an open standard for authorization and anyone can implement it.
- Microsoft's PRT is based on the OAuth 2.0 standard.
OAuth 2.0 is a standard that applications can use to grant client applications "secure delegated access." OAuth 2.0 operates over HTTPS and authorizes devices, APIs, and servers with access tokens instead of credentials (basic authentication).
In token-based authentication, access tokens are used to grant specific applications access to an API. After a user authenticates and authorizes access, the application receives an access token, which it then passes as a credential when calling the target API. The passed token informs the API that the bearer of the token has been granted permission to access the API and perform the actions specified by the authorization scope.
- When issued, the default lifetime of an access token is assigned a random value ranging between 60-90 minutes (75 minutes on average) (PRT is 14)
- Shared with requester(API) to gain access
- Should not live too long on the device in case of interception.
- Cannot be reused to other sign-in request also called SSO
When a client acquires an access token to access a protected resource, the client also receives a refresh token. The refresh token is used to obtain new access/refresh token pairs when the current access token expires. Refresh tokens are also used to acquire extra access tokens for other resources.
Refresh tokens are bound to a combination of user and client, but aren't tied to a resource or tenant. As such, a client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them.
- 24 hours for single page apps and 90 days for all other scenarios
- Refresh tokens keeps your Access tokens in check and ensure the validation is OK
- Ensure reauthentication if something has changed
- Allow users to be kept signed
To sum it up
The major difference between PRT and standard OAuth 2.0 is that we can reuse (SSO) across multiple applications, guarantee device identity, and require challenges (like MFA or compliance and much more).
Access and Refresh tokens are issued following authentication. A limited-lifetime access token is used to authenticate with a specific application. A refresh token is a special token used to acquire additional access tokens that will keep our session active. This allows you to have access tokens with a short lifespan without having to reauthenticate each time one expires.
Conditional Access Sign-In frequency (SIF) can be used to secure PRT by ensuring refresh tokens don't live too long, requiring full reauthentication before regaining a PRT (access token, refresh token, session keys, transport keys and challenges)