Table of Contents
Access, ID, and SAML2
ID tokens are JSON web tokens (JWT). These ID tokens consist of a header, payload, and signature. The header and signature are used to verify the authenticity of the token, while the payload contains the information about the user requested by your client. The v1.0 and v2.0 ID tokens have differences in the information they carry. The version is based on the endpoint from where it was requested. While existing applications likely use the Azure AD endpoint (v1.0), new applications should use the “Microsoft identity platform” endpoint(v2.0).
ID tokens and SAML2 tokens default lifetime 1 hour and the minimum 10 and maximum 1 day.
JWTs (JSON Web Tokens)
These tokens are splitted in to three sections.
- Header – Provides information about how to validate the token including information about the type of token and how it was signed.
- Payload – Contains all of the important data about the user or app that is attempting to call your service.
- Signature – Is the raw material used to validate the token.
Each piece is separated by a period (.) and separately Base64 encoded.
In example Federations Services uses JWT Tokens.
SAML 2.0 SSO
If and most of the time when you have problems with ADFS sign-in and tokens, these ones will be really useful on debugging the tokens.
And Microsoft has provided also other Online and Offline debugging tools for saml and token related problems, thanks Microsoft!
https://adfshelp.microsoft.com/
Refresh tokens
Below you can see the Refresh token revocation methods.
| Change | Password-based cookie | Password-based token | Non-password-based cookie | Non-password-based token | Confidential client token |
| Password expires | Stays alive | Stays alive | Stays alive | Stays alive | Stays alive |
| Password changed by user | Revoked | Revoked | Stays alive | Stays alive | Stays alive |
| User does SSPR | Revoked | Revoked | Stays alive | Stays alive | Stays alive |
| Admin resets password | Revoked | Revoked | Stays alive | Stays alive | Stays alive |
| User revokes their refresh tokens via PowerShell | Revoked | Revoked | Revoked | Revoked | Revoked |
| Admin revokes all refresh tokens for a user via PowerShell | Revoked | Revoked | Revoked | Revoked | Revoked |
| Single sign-out on web | Revoked | Stays alive | Revoked | Stays alive | Stays alive |
CAE
Continuous access evaluation (CAE) capable clients that negotiate CAE-aware sessions will see a long lived token lifetime (up to 28 hours)
And they keep the session open, regularly questioning that do I still need the connection or no.
The goal is for response to be near real time, but latency of up to 15 minutes may be observed because of event propagation time.
And the initial implementation of continuous access evaluation focuses on Exchange, Teams, and SharePoint Online.
And the following events are evaluated continuously.
- User Account is deleted or disabled
- Password for a user is changed or reset
- Multi-factor authentication is enabled for the user
- Administrator explicitly revokes all refresh tokens for a user
- High user risk detected by Azure AD Identity Protection
In the future there will be more.
Conditional Access policy evaluation
Exchange Online, SharePoint Online, Teams, and MS Graph can synchronize key Conditional Access policies for evaluation within the service itself.
Scenarios supported.
Why to use?
- User termination or password change/reset: User session revocation will be enforced in near real time.
- Network location change: Conditional Access location policies will be enforced in near real time.
- Token export to a machine outside of a trusted network can be prevented with Conditional Access location policies.
Token lifetime
Because risk and policy are evaluated in real time, clients that negotiate continuous access evaluation aware sessions no longer rely on static access token lifetime policies. This change means that the configurable token lifetime policy isn’t honored for clients negotiating CAE-aware sessions.
Token lifetime is increased to long lived, up to 28 hours, in CAE sessions. Revocation is driven by critical events and policy evaluation, not just an arbitrary time period. This change increases the stability of applications without affecting security posture.
If you aren’t using CAE-capable clients, your default access token lifetime will remain 1 hour. The default only changes if you configured your access token lifetime with the Configurable Token Lifetime (CTL) preview feature.
Final words
You should just enable it, there isn’t really no reason why you shouldn’t. The default setting inside your tenant is anyway the “Auto enable after GA” so it’s preferred to be enabled.
It helps your tokens to be flushed when credential leakage happen so you don’t have to do it manually.
You should, really.
And there is also another approach for keeping sessions nice and short and that is with Conditional Access policies. And not even allowing the options for users to save their logins.
And this is the setting it will override if you have it enabled.
That’s all, folks. Until the next time and then with Azure AD Identity Protection.
RSS - Posts