Use the IdP for decisions that must be consistent at sign-in and shared across many applications, and keep application logic for app-specific checks that depend on local context. If the decision needs to be portable, auditable, and current at the moment of token issuance, the IdP is the better control point.
Where the Decision Belongs: Shared Policy or App-Specific Logic?
Authorization belongs in the IdP when the rule is part of a common trust decision that should behave the same everywhere: who the user is, what roles or attributes they have, and whether access should be granted at sign-in or token issuance. That is the right place for portable policy, provided the IdP can evaluate it reliably and expose it to applications in a usable form.
Application code is the right place when the rule depends on local state the IdP cannot see, such as record ownership, tenant-specific workflow state, customer entitlements inside one product, or object-level checks tied to the current transaction. The practical question is not “can the IdP do it?”, but “should this decision be shared, or should it stay close to the resource?”
One useful way to think about the boundary is authorisation models: RBAC and coarse policy often fit the IdP, while richer application context often demands ABAC or relationship-aware checks inside the app.
What Changes at Sign-In, and What Must Wait for Runtime?
If a decision must be consistent across many applications, centralising it in the IdP reduces drift and makes the policy easier to audit. That is especially true for baseline access gates, step-up requirements, and decisions that should be applied before a token is issued. The moment you need the answer to be the same in every relying party, the IdP has a strong advantage.
Application-side authorization becomes stronger when the decision depends on the live state of the application, because only the application knows the object, the workflow, the tenant, or the business event currently in play. A token can say that a user is allowed into the system, but the app still has to decide whether that user may edit this invoice, approve this transfer, or view this record. In those cases, the IdP can provide identity context, but it should not be forced to be the final source of truth.
That boundary is why teams should keep a clear separation between portable policy and local enforcement. For teams building multiple products, a shared policy layer can prevent inconsistent decisions; for single applications with complex data rules, pushing everything into the IdP often creates a brittle policy model that is difficult to express, test, and change safely.
For teams standardising policy across services, Identity Provider and SSO Security Guide is a useful companion because it shows why sign-in time controls, federation, and token handling matter when the IdP is acting as the decision point.
How Teams Avoid Overcentralising Authorization
The common failure mode is to treat the IdP as the answer to every access question because it is convenient. That works until the application needs context the IdP does not have, or until teams start encoding business logic into identity policy just to avoid writing app checks. At that point, the policy becomes hard to reason about, and changes can break unrelated applications.
A better pattern is to decide the control point by the stability of the rule and the data needed to evaluate it. If the rule is stable, broadly reusable, and based on identity attributes or roles, centralize it. If it is dynamic, object-specific, or driven by application state, keep it in the app and treat the IdP as an input, not the final decision engine. That division also makes it easier to test who is responsible when access is denied, granted, or changed.
Where organisations support machine or service access as well as user access, the same principle still applies: shared authorization policy belongs near the trust boundary, while action-specific checks belong where the action is executed. In other words, central policy is best for consistency; local logic is best for precision.
A practical reference point is Authorisation Models Guide, which helps teams separate coarse, shared decisions from more context-sensitive enforcement patterns.
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, OWASP ASVS and NIST CSF 2.0 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 placement directly affects where access enforcement is executed. |
| IA-5 — Authenticator Management | IdP decisions depend on controlled tokens, claims, and lifecycle-managed authenticators. | |
| AC-6 — Least Privilege | Choosing IdP or app impacts how narrowly access can be scoped and enforced. | |
| Recommendation — Enforce AC-3 at the most complete decision point, then apply compensating app checks where local context is required. Manage authenticators and token-bearing material so central authorization decisions remain trustworthy. Apply AC-6 to keep shared policy coarse and app logic narrowly scoped to the resource. | ||
| OWASP ASVS | V8 — Authorization | The question is about where application authorization decisions should be implemented and verified. |
| Recommendation — Design V8 checks so the application still enforces object- and function-level access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The decision affects how access control is implemented across shared identity and application layers. |
| Recommendation — Use PR.AA-05 to align shared identity policy with application-specific access enforcement. | ||
Practitioner Guidance
What to prioritise: Start by classifying each authorization rule as shared policy or app-local decision. If the rule must be identical across applications, decide whether the IdP can express and enforce it without losing business context; if not, keep it in the application and pass only the identity facts the app needs.
What to verify: Before moving authorization into the IdP, verify that the IdP can evaluate the rule at token issuance time, that downstream apps will actually consume the claim or assertion consistently, and that there is a fallback plan for app-specific checks the IdP cannot represent.
Common mistake: Teams often centralize too aggressively and then recreate application logic in identity policy. That usually produces opaque rules, slower change cycles, and weak accountability when a decision is wrong.
Practitioner takeaway: Put the decision at the highest layer that still has the facts needed to decide correctly, but no higher. If the IdP can make the rule portable and consistent, use it; if the app needs local context to avoid overgranting access, keep the final check in the app.