Identity, Tokens and Authorization

Two systems, not one

First you prove who you are. Then something decides what you may do. Authentication and authorization are different systems with different failure modes, and much of the confusion in identity design comes from treating a successful sign-in as if it settled the second question too.

The question to ask of any identity design is: who is the caller, who vouched for them, what may they do, for how long, and how is that taken away?

The vocabulary

• Principal: whatever is acting. There are now three kinds: humans, workloads, and AI agents.
• Credential: what a principal uses to prove itself. A password, a key, a certificate, a federated assertion.
• Token: what a principal gets after proving itself. An ID token says who someone is. An access token says they may call a particular audience. A refresh token lets them get more access tokens without signing in again.
• Claims: the statements inside a token. The ones that matter most are the issuer (iss), the audience (aud) and the expiry (exp).
• Signing keys: the issuer signs tokens with a private key and publishes the public half as a JSON Web Key Set (JWKS), so any resource can check a signature.
• Federation trust: one system agreeing to accept another's tokens.
• SCIM: the protocol that creates, updates and removes accounts and group memberships across systems.
• RBAC, ABAC, ReBAC: authorization by role, by attribute, and by relationship.
• PDP and PEPPDP and PEPThe policy decision point decides whether a request is allowed; the policy enforcement point carries the decision out. They are often different components.Identity and authorization: the policy decision point, which decides, and the policy enforcement point, which enforces. They are often different components, and the model in an AI system is never the PEP.

How a resource validates a token

When a request arrives with an access token, the resource checks the signature against the issuer's cached public keys, then checks the issuer, the audience, the expiry and not-before times (against its own clock), and the scopes. That's local validation, and it matters for resilience: a resource that validates locally keeps working through an identity-provider outage until the tokens expire or the keys rotate. It is statically stable for that long.

Introspection is the alternative: the resource asks the identity provider, on every request, whether the token is still good. That gives instant revocation and makes every request depend on the identity provider being up. It is not statically stable at all.

Event-driven revocation sits between the two. The identity provider pushes "this session is revoked" events to resources that subscribe. It needs an event channel, and it only helps at the resources that take part.

The consequence is a trade you can't avoid: longer tokens buy availability and cost revocation latency. And the overlap window when signing keys rotate becomes a resilience setting, because a rotation without overlap invalidates every token in flight at once.

Revocation, and continuous access evaluation

Without events, a stolen access token works until its exp. Microsoft Entra's continuous access evaluationContinuous access evaluationMicrosoft Entra's event-driven revocation. Tokens can last up to 28 hours, and events such as a disabled account revoke them at resources that take part.Microsoft Learn on CAE (opens in a new tab) (CAE) changes the shape of that: tokens in CAE sessions can live up to 28 hours, and critical events such as a disabled account or a password reset revoke them at participating resources^[1]. Clients that don't support CAE stay near the default lifetime of about an hour, and the shortest configurable access-token lifetime is ten minutes.

So CAE doesn't remove the revocation problem. It moves freshness from expiry to events, at the resources that take part. A resource that doesn't participate accepts a 28-hour token for its whole life.

Groups propagate on token refresh, not instantly. Tokens can carry group claims, and the token Azure Resource Manager receives includes transitive group memberships. Remove someone from a group and their existing token still says they're in it until it's refreshed.

The revocation window

Put those delays together and you get the number this atlas asks every design to state: W_revoke, the longest time a removed permission can still be used.

It's the sum of four delays:

1. the remaining validity of the token, or the event-revocation delay at resources that take part in CAE
2. the TTL of any cached authorization decision
3. the lag in synchronising group membership
4. the lag in synchronising ACLs into any search index

Set it per data class. Confidential data might need W_revoke under an hour. Public reference material might tolerate a day. Prefer event-driven invalidation over long TTLs where resources support it. Never cache an allow for an irreversible action. And note that caching a deny is safe for security and bad for availability, because a cached deny keeps refusing after the problem is fixed.

On-behalf-of, and why a token is never forwarded

When an agent or a middle-tier service calls something on a user's behalf, it shouldn't pass the user's token along. It should exchange that token, which was issued for itself, for a new one issued for the next audience. That's the on-behalf-ofOn-behalf-ofA token exchange: a middle tier trades the token it was given for a new one issued to the next service, so the user's own token is never passed along.Microsoft Learn on the OBO flow (opens in a new tab) flow.

Entra enforces the audience binding for agents strictly: a user assertion presented by an agent must have an audience equal to the agent identity blueprint's client ID, and tokens issued for other resources are rejected with AADSTS50013^[2]. Blueprints can't start interactive /authorize flows themselves.

Passing a token through unchanged creates a confused deputy: the downstream service can't tell which hop it is really talking to, and a token issued for one API can be replayed at another. The retrieval and agents page draws the right shape.

Architecture that holds up

• One central identity provider, federated to the clouds and to SaaS. Authentication centralises; authorization stays distributed, at each resource.
• Workload identity federation everywhere. CI pipelines and Kubernetes workloads present an OIDC token from their own platform and get short-lived cloud credentials in exchange. No static keys to leak.
• Just-in-time elevation for administrative roles, rather than standing privilege.
• Break-glass accounts outside Conditional Access, on hardware keys, monitored on every use, and tested.
• Tiered administration, so that the accounts that can change identity itself are few, separate and watched.
• A separate customer identity system (CIAM) for customers, not the workforce tenant.

How identity fails

• An identity-provider outage stops new sign-ins and token refreshes. Existing tokens keep working until they expire, which is why token lifetime is a resilience parameter.
• Signing-key rotation without overlap causes mass validation failures across every resource at once.
• Clock skew makes valid tokens "not yet valid".
• Consent phishing: a user grants a malicious app broad delegated permissions.
• Stale group claims after someone leaves.
• Confused deputies through token pass-through.
• Theft of an agent blueprint's credential, which can mint tokens for every agent created from it.

The second- and third-order effects

Identity is the first dependency, and the consequences run further than they first appear.

• Workload identity federation makes the identity provider, the STS and its signing keys Tier-0 for machines too. A federation outage is a machine outage.
• SCIM lag becomes authorization lag.
• Agent identities add a third kind of principal, whose credential lives on the blueprint.
• Authorization latency adds up per hop.
• Dependency loops appear. The identity provider depends on DNS, the network and a database. If it runs on the platform it authorizes, recovering the platform needs the identity it has just lost.
• Identity telemetry is Tier-0 telemetry. Sign-in logs and token issuance rates are often the first signal of compromise.
• Changing identity provider is a Type-1 decision, one that is expensive to reverse, because every federation trust, OIDC issuer URL and audience value is a hard-coded edge somewhere.
• A tenant compromise is a total compromise, so tiered administration and the identities that can grant permissions are the true Tier-0.

Trade-offs

Short tokens against long tokens with CAE. Short tokens revoke quickly and lean on the identity provider. Long tokens with CAE keep working through outages and depend on the event channel and on resources participating.

Central against per-application authorization. A central PDP gives one place to audit and one place to fail.

RBAC against ABAC and ReBAC. Roles are simple, coarse and easy to review. Attribute and relationship models are precise and much harder to audit.

By provider

Questions to ask in a review

What is W_revoke for this resource? Does it honour CAE events? What breaks when the JWKS rotates? Who can grant permissions, and are those identities in the Tier-0 set? Is the user's token ever forwarded? Where do the break-glass credentials live, and when were they last used?