Authorization inside an IdP tends to break when access rules need more than static roles and token claims. Once tenants, resources, and context vary at request time, teams end up duplicating logic across services or hardcoding exceptions in application code. The result is drift, stale decisions, and weak auditability across the access stack.
Why authorization-in-the-IdP works at small scale, then starts to crack
Keeping authorization inside an identity provider can be efficient when access is mostly coarse-grained: a few roles, a few apps, and decisions that fit cleanly into token claims. The model starts to strain when each request needs tenant, resource, or context-aware decisions. At that point, the IdP becomes a policy bottleneck rather than a source of authoritative identity signals.
Once the application needs to decide access based on who is asking, what they are asking for, and in what context, the authorization logic stops being a static login-time concern. That is the core difference between an IdP that issues identity assertions and an application that must enforce fine-grained access rules at runtime.
A useful way to see the boundary is through the access model itself. Authorisation Models Guide covers the shift from simple role checks toward ABAC, ReBAC, and policy-based decisions, which is exactly where IdP-only patterns begin to lose fit.
What breaks in the application stack when policies stay centralized
The first failure is decision drift. If one service still trusts token claims while another compensates with local code, the same user can receive different outcomes depending on which path they hit. The second failure is exception sprawl: teams hardcode tenant-specific or resource-specific overrides in application logic because the IdP cannot express the rule cleanly.
That usually creates duplicated policy fragments across services, each one slightly different. Over time, the application stops having a single enforceable authorization model and instead accumulates a set of local interpretations that are difficult to compare, review, or retire.
This is why teams often move toward a more explicit authorization layer rather than relying on login-time claims alone. The Authorisation Models Guide is especially relevant when you need one policy model that can handle people, workloads, and agents without forcing every app to reinvent the same checks.
For operational security, the same pattern shows up in broader access governance. IAM and IGA Basics is a good reference point for the distinction between authentication, entitlement control, and access review, which is exactly the separation that gets blurred when the IdP is expected to do everything.
Why stale decisions become an auditability problem, not just a design smell
Once authorization logic is embedded in application code, policy changes become harder to trace. Security teams may know who can log in, but not why a particular request was allowed, which rule applied, or whether two services evaluated the same request differently. That weakens auditability, incident response, and change control.
The problem gets worse when access rules depend on conditions that change after token issuance, such as tenant membership, resource ownership, device state, or request context. A token can remain valid while the business decision it represents has already gone stale. At that point, the system is not just inconvenient to maintain, it is making authorization decisions from outdated assumptions.
Hardened identity flows help, but they do not solve the whole problem if authorization remains static. The Identity Provider and SSO Security Guide is useful for understanding how the IdP should protect authentication, session integrity, and federation trust, while still leaving runtime access decisions to the right control point.
For the underlying protocol boundary, RFC 6749: The OAuth 2.0 Authorization Framework remains a key reference for separating token issuance from downstream resource access, even though real-world fine-grained authorization usually needs more than the token alone.
Risk and Threat Considerations
When authorization stays inside the IdP after the application grows, the main risk is that the IdP becomes a single decision choke point while the apps quietly compensate with local shortcuts. That creates inconsistent enforcement, stale permissions, and a larger blast radius if a claim, mapping rule, or federation trust assumption is wrong.
Failure mechanism: Teams encode access exceptions in claims, app code, or per-service conditionals because the central policy model cannot express request-time context cleanly, so different paths diverge over time.
Impact: Access decisions become harder to reason about, harder to audit, and easier to bypass through alternate code paths, especially when tenant, resource, or environment context changes frequently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Authorization decisions must be enforced consistently at the access point. |
| IA-2 — Identification and Authentication (Organizational Users) | The IdP remains the authority for authenticating the user or subject before access decisions. | |
| AU-2 — Event Logging | Weak auditability is a core failure mode when authorization is scattered across apps. | |
| Recommendation — Enforce access decisions where the resource is actually protected. Preserve strong authentication in the IdP and separate it from authorization logic. Log authorization decisions and policy inputs so reviewers can trace why access was allowed. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Context-aware, policy-based access aligns with zero trust principles rather than static claim checks. |
| Recommendation — Place continuous policy evaluation at the enforcement point instead of relying on one-time trust. | ||
| OWASP ASVS | V8 — Authorization | Application authorization should be verified as a distinct control when rules exceed simple roles. |
| Recommendation — Verify that each protected action has explicit authorization checks. | ||
Practitioner Guidance
What to verify: Check whether the application still needs request-time variables that are unavailable at token issuance. If yes, treat the IdP as an identity source, not the final authorization engine.
Decision rule: If a rule changes per tenant, resource, or action, keep the policy close to the enforcement point and use the IdP only for authoritative identity and coarse claims. If the rule is static and universal, central claims may still be enough.
Common mistake: Treating “fewer policy services” as the same thing as “simpler authorization.” In practice, that often just hides complexity inside application code and makes reviews less reliable.
Practitioner takeaway: The design boundary matters more than the product boundary, authorization should live where the request context is visible, while the IdP should supply identity signals that remain stable and trustworthy.
Related resources from NHI Mgmt Group
- How should teams structure authorization so it stays maintainable as applications grow?
- What breaks when PKI stays tied to fixed infrastructure as applications and certificate demand grow?
- What is the difference between protecting applications and protecting access?
- What breaks when authorization is rebuilt inside each service?