When a user signs in, your identity provider hands them a token. That token gets passed to every downstream system the user touches, and inside it sits a list of claims, scopes, groups, and roles that say what the user is allowed to do.
That list is an authorization decision. Most identity teams don't manage it like one.
The roles get assigned in the IdP. The scopes are configured per client. The groups come from an IGA tool. The claims are mapped to OIDC scopes by whoever set up the integration originally. Once the token is signed, it travels around your environment for an hour or more, and every relying system trusts it. If something in that list is wrong, stale, or too broad, you find out from the audit logs or you don't find out at all.
This is where authorization governance falls through the floor for most teams. Authentication is solved. The joiner-mover-leaver lifecycle is solved enough. But what gets baked into the token at issuance is a governance decision that often has no owner, no audit trail, and no policy.
Why IdPs can't make authorization decisions alone
An IdP is good at one thing. It knows who the user is. It checks credentials, runs MFA, enforces session policy, and produces a verifiable assertion of identity.
What it doesn't know is the full state of the systems the user is about to access. It doesn't know which tenant the user is currently scoped to in the application. It doesn't know whether the project they're requesting access to has been put on hold by compliance. It doesn't know that this user, who is normally a senior reviewer, has been temporarily downgraded because they're on the same deal as the counterparty. It doesn't know the device posture, the IP reputation, or whether the user has open exceptions in your risk system.
When the IdP issues the token, it pulls claims from the directory, maps them through whatever configuration exists, and stamps the result. The token is now the authoritative source of truth for what this user can do for the next hour. If any of that contextual state changes during that hour, the token doesn't notice.
That's the static token problem. It isn't a flaw in the IdP. It's a category error. The IdP was built to assert identity. We've ended up using it to assert authorization too, and the two are not the same.
It's also why teams in this space have started talking about the shift from snapshot governance to runtime governance. Admin-time decisions, like which roles a user has and which scopes a client gets, capture a moment in time. Runtime decisions reflect what's actually true the instant the action happens. Static tokens are pure snapshot governance. Once issued, they keep saying what they said at issuance until they expire, regardless of whether the situation underneath them has changed.
What policy adds at issuance
The pattern that's emerging across mature identity stacks is to separate the two cleanly. The IdP still authenticates. Before the token is signed, the contents go through a policy evaluation that has access to context the IdP doesn't have.
That policy can pull from your IGA tool for the current entitlement state. It can pull from the application's data layer to see which tenants the user is currently associated with. It can read device signals from your endpoint platform. It can reflect risk scores from your SIEM. It can check whether the user has a recently filed exception or a recently revoked credential. None of that lives in the IdP. All of it should influence what's in the token.
The result is a token whose claims, scopes, and group memberships are the output of a policy that took current context into account at the moment of issuance. The IdP still does its job. What the relying systems trust downstream is no longer a static mapping. It's a decision.
Gartner's recent framing of this space calls these systems Authorization Management Platforms. In their model, an AMP sits alongside the IdP and provides the policy administration, evaluation, and orchestration that authorization decisions need. Three patterns sit underneath that. Token-facilitated authorization, where the AMP decides what goes into the token at issuance. Externalized authorization, where applications call out to the platform at decision time. And policy orchestration, where the AMP makes its decisions available to systems that speak their own authorization protocols. We've written about the AMP category in more depth.
Token-facilitated authorization is a sensible starting point for most identity teams because it doesn't require the relying systems to change. They still consume the same tokens they always have, whether that's OAuth2, OIDC, or SAML assertions in the legacy estate. What changes is who decides what's in them. The way claims map to OIDC scopes becomes a policy concern, not a configuration concern.
The wire formats are evolving in the same direction. Three IETF drafts now formalise what the standards community has started calling the subject-as-vector shift. The OAuth Actor Profile draft, published in April 2026, defines how delegated actor relationships ride inside JWT access tokens through the act claim chain. A companion entity profiles draft adds sub_profile and client_profile claims so a relying system can tell whether the acting entity is a user, an AI agent, a service, or a device. A third draft, on client instance assertions, adds client_instance so the runtime that produced the request can be distinguished from the registered client class.
Read together, these say something structural. The subject of an authorization request is no longer a single principal. It's a vector. The request carries a chain of issuers and entities, and the policy has to evaluate against the whole thing rather than picking one as the principal. The token at the end of issuance reflects a structured decision about who is acting, on whose behalf, with what authority, and from which runtime. That decision belongs in policy.
What token-facilitated authorization gives the identity team
The reason this pattern matters for IAM leaders, not just developers, is that it brings authorization decisions inside the governance perimeter. The thing you've never had visibility into now has a policy, a decision log, and a clear owner.
Visibility is the first benefit. Every token issued is the result of a policy evaluation, and every evaluation is logged with the inputs that drove it. You can answer questions like which claims a service account has been issued in the last 24 hours, and why, without writing a custom report. The decision log becomes the audit trail for authorization, not just authentication.
Instant revocability is the second. If you discover a role mapping is wrong, or a contractor's access needs to be cut, you change the policy and the next token issued reflects it. You aren't waiting for tokens to expire or pushing emergency invalidation across every relying system. The control point moves to one place.
Lifecycle alignment is the third. Joiner-mover-leaver events in your IGA tool feed the policy that decides token contents. When someone changes roles, the next token they're issued reflects the new role automatically. You no longer need to chase down hardcoded permission mappings in application code or in IdP client configurations. The same is true for non-human identities. Service accounts, workloads, and AI agents go through the same policy, so the tokens they're issued reflect current context, current scope, and current entitlement state.
The AI agent point is worth pulling out separately. Boards have mandated AI adoption. Identity teams are responsible for governing it. The most common failure mode is that an agent gets issued a token with broad claims at startup and runs against those claims for hours, regardless of what the agent is actually doing in the moment. The window of tolerable over-privilege used to be measured in days, because humans take lunch, go home, and operate inside business hours. Agents don't. They run at machine speed, around the clock, across every time zone at once. An over-privileged token in agent hands gets exercised continuously, and an action that would have taken a misconfigured human three months to discover gets exercised in minutes. Policy-driven issuance lets you narrow the claims to the specific tool call, the specific user the agent is acting on behalf of, or the specific data scope the request needs. The kill switch is a policy edit, not a deployment. We've written about the dimmer switch model for governing AI agents.
Externalized authorization and policy orchestration, the other two AMP patterns
Token-facilitated authorization is the easiest entry point, and it works alongside two other patterns that share the same policy layer.
Externalized authorization is the pattern for new applications, or for fine-grained checks inside an application that the token can't carry. The application asks the platform at decision time whether the current user can perform this specific action on this specific resource, given the current state of both. Tokens carry coarse claims. The decision point handles the fine ones.
Policy orchestration is the third pattern, and it's where most AMPs trip themselves up. The conventional approach translates policies into the native language of each relying system and pushes them out so the relying system can evaluate decisions locally. The cost is that policy now lives in two places. It drifts. Decisions diverge. The audit trail fractures.
The model worth using inverts this. The policy and the evaluation stay centralised. What gets adapted is the wire protocol on the inbound side. A proxy sits in front of the decision point and accepts authorization requests in whatever protocol the relying system speaks, whether that's Envoy external authorization, an OPA-shaped endpoint, Kafka, Trino, Kubernetes admission control, or anything else that supports delegating authorization over HTTP. The proxy translates the inbound request into a native decision call, the policy evaluates once against current attributes, and the answer is translated back into the relying system's native response format. One policy, one engine, many wire-protocol facades. Cerbos Synapse is the component that plays this role in the Cerbos stack.
The three patterns aren't competing. They're complementary, and which one fits depends on the system. Tokens cover the legacy and federated estate. The decision point covers the modern, fine-grained estate. The orchestration proxy covers the infrastructure estate, the systems that speak their own protocols. The policy is the same in all three places.
Common traps when adopting policy-driven token issuance
The trap most teams fall into is treating policy-driven token issuance as a bolt-on to the IdP. They write a custom plugin, hardcode the logic into a token mapper, and call it done. That works for one IdP, for one set of claims, until someone wants to add a different IdP, extend the same policy logic to a new relying system, or audit what the policy looked like six months ago. At that point you've recreated all the problems you started with, just inside a different layer.
The other trap is vendor lock-in. If the platform that decides token contents speaks a proprietary protocol to the IdP, you've made the IdP and the AMP one stack. Standards work matters here. AuthZEN, the OpenID Foundation standard for the wire protocol between policy decision points and the systems that call them, was finalised in January 2026. It's what makes this pattern portable. Picking a platform that speaks AuthZEN means the policy layer is decoupled from the identity layer.
The third trap is over-broad policies. Policy-driven token issuance is only as good as the policies you write. If the policy says "any authenticated user gets the same claim set the IdP would have issued statically," you've moved the problem, not solved it. Use the context the policy now has access to. Narrow the claims. Reflect the moment. The whole point is to issue tokens that are appropriate to the request, not tokens that are convenient to issue.
The fourth trap is asking application developers to validate the tokens themselves. In the simple world, a request carried one bearer token from one issuer and any backend could verify the signature. In the world the IETF drafts are now codifying, a request carries a chain of issuers, each with its own trust level, plus an actor profile, plus an instance assertion. No application team should be writing N-token validation logic, and the ones that try will get it wrong. Move validation into the platform that evaluates policy. It already has to read the tokens to make the decision. Centralising both is the only architecture that scales as the wire formats get richer.
The next maturity step for authorization governance
Identity has spent the last decade getting authentication right. Federation, MFA, passwordless, FIDO2, conditional access, all of it has moved the discipline forward. Authorization, the question of what authenticated identities can actually do once they're in, is roughly where authentication was a decade ago. The standards are catching up. The platforms are catching up. Most teams still have policy in code, policy in IdP config, policy in IGA workflow, and no single place that owns the question. The organisational habit of treating authorization as whatever the application happens to do is what has to catch up next.
Policy-driven token issuance is the first step toward closing that gap inside the identity team's perimeter. The token is the moment identity hands off to application. Make that moment a policy decision. The visibility, the audit trail, and the control follow.
Try Cerbos to see how policy-driven authorization works in practice, or book a call to walk through how token-facilitated authorization can benefit your organization.
Go deeper:
- How to adopt externalized authorization (eBook) for a step-by-step playbook on decoupling authorization from application code.
- The IAM security checklist for 2026 (Checklist) for a structured way to find gaps in your current identity stack.
FAQ
Tagged in
