No, I am not going to bore you to tears with another article on how refresh tokens, access tokens and session cookies work and how their implementation in Microsoft Entra ID looks like.
In this article, I would rather like to consider specific sub-types of refresh tokens and session cookies and under which circumstances can they be revoked (or not!).
Tokens vs cookies - how do they differ?
Refresh tokens and session cookies are different types of long-lived tokens.
They are issued from a single root authentication event. Usually, it’s an interactive authentication in the case of human operated identities.
Key difference between them?
- Refresh tokens are issued when interacting with applications using OAuth2 framework (i.e. mobile, desktop apps and web applications calling secured APIs in the background).
- Session cookies are issued when interacting with, web (HTTP-based) applications. In this article, I am only considering session cookies issued by Entra ID to Microsoft first party web apps.
Differences within the family
We can distinguish password-based and non-password-based tokens/cookies.
Password-based refresh tokens and session cookies are issued and tied to an interactive authentication that used password as part of the authentication flow.
As you might infer, non-password-based tokens/cookies are issued and linked to an interactive authentication that didn’t use password as part of the authentication flow.
Examples include FIDO2 security key or passkey-based authentication, using Microsoft Authenticator passwordless phone-based sign-in, Temporary Access Pass, certificate based authentication, as well as SMS-based or recently added QR code sign-in.
Impact on incident response
All cool, but let’s ask the important question - what happens if a Security Operations team, performing a response to a user identity compromise, decide to just reset the user’s password. Does this action remediate the risk well enough?
Unfortunately not - all non-password-based tokens and session cookies tied to the compromised user identity will stay alive and active. Only password-based post-authentication artifacts are revoked!
However, if Security Operations team perform an admin revocation of user tokens - all kinds of tokens and cookies, regardless of their sub-type, are revoked.
It is therefore imperative that SOC teams incorporate not only user password reset, but also admin revocation of refresh tokens, as part of their identity compromise response playbooks.
To build comprehensive identity compromise response playbooks, familiarize yourself with phishing, password spray and token theft response.
Below table summarizes what happens to tokens/cookies after administrative actions:
| Action | Password-based token | Password-based session cookie | Non-password-based token | Non-password-based session cookie |
|---|---|---|---|---|
| Admin forces password reset | Revoked | Revoked | Valid | Valid |
| Admin revokes all refresh tokens | Revoked | Revoked | Revoked | Revoked |
How to perform admin revocation of all tokens and session cookies?
PowerShell Graph SDK way (required directory roles needed neatly documented here, Graph API permissions here:
Import-Module Microsoft.Graph.Beta.Users.Actions
Connect-MgGraph
Invoke-MgBetaInvalidateAllUserRefreshToken -UserId <UserPrincipalName or object ID>
ClickOps (GUI) way:
What about external (B2B) users?
As an admin of a resource tenant, you can’t revoke the tokens and session cookies issued to external users domiciled in another Entra ID tenant or externally federated organization. Such users must have their tokens revoked in their parent organization.
Useful resources:
- Entra ID directory roles with invalidate all refresh tokens permission
- MS Graph permissions - user: invalidateAllRefreshTokens
- Refresh tokens in the Microsoft identity platform
- Authentication methods reference claim in access tokens
All work is licensed under a Creative Commons Attribution 4.0 International License.
