Should organisations keep the IdP in the authorization path?

Yes, but only as an input source for identity data, not as the full permission system. The IdP should prove who the principal is, while a separate policy layer decides whether that principal can perform the action on the resource in context. That separation keeps authentication and authorization from being forced into one model.

Why the IdP Should Not Be the Policy Engine

The cleanest model is to let the IdP assert identity and session context, while a separate authorization layer decides access based on resource, action, and environment. That separation matters because identity proof alone rarely answers the real question, which is whether this principal should do this specific thing to this specific asset right now. Conflating the two usually leads to coarse rules, brittle exceptions, and access decisions that are hard to explain or audit.

When organisations keep the IdP in the authorization path as the source of truth for identity, they preserve a strong trust boundary and reduce the temptation to overload directory groups with business logic. That is especially important where roles change often, resources have different sensitivity levels, or context such as device posture, location, transaction value, or workflow state affects access. A separate policy layer also makes revocation, review, and testing more manageable because the access logic is not buried inside identity records. For broader access-control structure, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point for separating account management, access enforcement, and monitoring. In practice, many teams discover the weakness only after a directory cleanup or audit exception exposes how much application access depended on group sprawl.

How It Works in Practice

A workable pattern is to treat the IdP as an input source that authenticates the subject and supplies stable identity attributes, then pass those attributes into a policy decision point or authorization service. The policy layer should evaluate the action, the target resource, and any contextual signals the application trusts, then return a permit or deny decision. That keeps authentication concerns, such as login, MFA, and session state, separate from authorization concerns such as permissions, scopes, entitlements, and contextual conditions.

The IdP asserts who the principal is and may provide claims such as department, tenant, or assurance level.
The application or policy service evaluates whether that principal can access the requested resource under current conditions.
The decision should be logged separately from the login event so reviewers can trace both identity proof and access logic.
Revocation should be handled through the policy layer and entitlements, not by embedding business logic inside directory groups.

This model works best when claims are treated as inputs, not permissions. A department claim may help determine eligibility, but it should not by itself grant access to a sensitive record. Likewise, a successful login should not be interpreted as blanket authority for every downstream action. If a system needs coarse, static access only, direct IdP group checks can be sufficient, but once context, shared resources, or delegated actions enter the picture, the policy layer becomes necessary. The strongest implementations also version their policies and test them against real request patterns so that identity changes do not silently alter access outcomes. These controls tend to break down when application teams encode authorization rules directly in SSO group mappings because the resulting logic is opaque, difficult to change safely, and prone to privilege creep.

Common Variations and Edge Cases

Tighter separation often increases design and governance overhead, so organisations have to balance simplicity against control quality. Some environments do accept a lighter model for low-risk applications, but that tradeoff should be explicit because the access model becomes less expressive as soon as the IdP carries too much of the decision.

One common edge case is systems that rely on claims-based access for speed or convenience. That can work when claims are narrowly scoped and the resource sensitivity is low, but it becomes fragile when teams start using the same claims for both identity proof and fine-grained permissioning. Another variation is legacy applications that cannot call a separate policy service; in those cases, proxy enforcement or a gateway layer is often the safer compromise. A useful practitioner rule is to keep the IdP authoritative for identity state, but not for business authorization logic. The more dynamic the resource, the more dangerous it is to use static identity attributes as a proxy for permission.

NHIMG research on NHI exposure also shows why keeping control boundaries clear matters in machine-access environments: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. Those figures point to a broader pattern, which is that overloading one control plane with both identity and entitlement logic tends to hide risk rather than reduce it. Where the operating model includes many automated principals, the case for a separate authorization layer becomes stronger, not weaker. Organisations that need a reference for control separation can also anchor their design to established access-control guidance, including NIST SP 800-53 Rev 5 Security and Privacy Controls, while keeping implementation decisions local to the application and policy architecture.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Covers separating authentication from access decisions for resource protection.
	PR.PT — Protective Technology	Supports enforcing policy outside the IdP with technical access controls.
Recommendation — Separate identity proof from authorization enforcement and review access decisions independently. Implement policy enforcement points that control access based on context and entitlement.
NIST SP 800-63	AAL — Authentication Assurance Level	Authentication assurance informs identity confidence, not the authorization decision itself.
Recommendation — Use assurance levels to judge identity strength, then apply separate authorization policy.
NIST Zero Trust (SP 800-207)	Policy Decision Point / Policy Enforcement Point — Policy Decision Point and Policy Enforcement Point	Zero trust relies on central policy decisions separate from identity assertion.
Recommendation — Route access through a policy decision point rather than trusting login alone.
CIS Controls v8	6 — Access Control Management	Prescribes managing access independently of authentication source and group sprawl.
Recommendation — Centralise access review and enforcement so permissions do not live only in directory groups.

Practitioner Guidance

What to prioritise: Preserve the IdP as the source of identity assertions, then decide which permissions must be enforced by a separate policy decision path. If the IdP is also carrying business rules, split that responsibility before access logic becomes too embedded to unwind.

What to verify: Check whether a successful login currently implies more authority than the organisation intended. Review the highest-risk applications first, especially those with sensitive data, delegated access, or rapidly changing business context.

Decision rule: If the access question depends on resource sensitivity, action type, workflow state, or environment, use a policy layer. If the question is only whether the principal is authenticated and minimally eligible, the IdP can stay in the path as an input source.

Practitioner takeaway: The safest design is usually not the most convenient one for the directory team, it is the one that makes identity proof and permissioning independently testable, revocable, and explainable.