1.4.3. Token Anatomy and Lifetimes
💡 First Principle: A token is trustworthy because of what's inside it and how long it lives. Claims carry the facts, a digital signature makes tampering evident, and short lifetimes bound the damage window if one is stolen — every lifetime setting is a deliberate trade between user convenience and revocation speed.
Entra tokens are JWTs — three Base64 segments (header, payload, signature). The payload's claims are name/value facts the app consumes. The ones worth recognizing on sight: iss (issuer — which tenant authority signed this), aud (audience — the one app or API this token is for), sub/oid (the principal), scp/roles (delegated scopes or app roles — the authorization payload), exp (expiry), and amr (how the user authenticated — e.g., MFA). Apps must reject a token whose audience isn't them; a token for Graph proves nothing to your custom API.
Lifetimes create the rhythm of access. Defaults to reason from: access tokens live roughly 60–90 minutes; refresh tokens live days-to-indefinite with sliding renewal; a web session cookie at the IdP persists per policy. The refresh moment is the policy chokepoint: each time a refresh token is redeemed, Entra can re-run Conditional Access, notice the user is now disabled or risky, and refuse. Between refreshes, an already-issued access token sails on — the hotel keycard problem from 1.4's intro. Two mechanisms shrink that gap: revocation (revokeSignInSessions invalidates refresh tokens, forcing reauthentication at next refresh) and continuous access evaluation (CAE), where capable services (Exchange, Teams, SharePoint) subscribe to critical events — account disabled, password changed, network change — and reject even unexpired tokens in near real time.
⚠️ Exam Trap: Revoking sessions kills refresh tokens, not outstanding access tokens. Without CAE, a terminated employee can retain up to ~an hour of access to non-CAE services. The complete, exam-correct offboarding sequence is: disable the account, then revoke sessions, then rely on CAE/expiry to close the tail.
Reflection Question: Using claims vocabulary — which claim would a resource API check to refuse a stolen token that was issued for a different API, and which claim tells it the user satisfied MFA?
