1.4. Tokens and Modern Authentication Protocols
💡 First Principle: Cloud identity works only because proof of authentication can travel. A token is a signed, time-limited statement from the identity provider — "I verified this principal; here are the facts (claims) about them" — that any trusting application can validate without ever seeing a password. Sign in once to the IdP, present tokens everywhere: that's single sign-on, federation, and API security in one mechanism.
Why care as an administrator rather than a developer? Because token mechanics explain the behaviors the exam probes: why a disabled user keeps working for a while (their access token hasn't expired), why Conditional Access re-evaluates when a token is refreshed, why consent screens list scopes, and how one tenant can trust another's sign-ins. When troubleshooting stems mention "the user still has access after being disabled," they're testing token lifetimes, not directory replication.
The hotel keycard is the mental model that fits. Front desk = identity provider: it checks your passport once, then issues a keycard (token) encoding your room and checkout date (claims and expiry). Doors (apps) don't call the front desk on every swipe — they trust the card's validity until it expires. Lose your card or check out early, and the hotel can re-encode the locks (revocation) — but until a door next checks, an old card may still work. Every token behavior on the exam maps onto that tension between convenient offline trust and timely revocation.
⚠️ Common Misconception: "Disabling an account instantly cuts off all access." Issued access tokens keep working until they expire — commonly around an hour — unless the service participates in continuous access evaluation or you explicitly revoke sessions. Complete offboarding is always disable + revoke, a pairing Phase 2 returns to.
