How do I know if authorization should be separated from the IdP?

Why This Matters for Security Teams

Authorization and identity are related, but they solve different problems. An IdP proves who or what is logging in, while authorization decides what that entity can do, under what context, and for how long. When those layers are fused too tightly, teams often inherit brittle policy logic, inconsistent enforcement, and slow change cycles that make audits and incident response harder than they should be.

This separation becomes more important as environments add service accounts, APIs, and agents that do not behave like human users. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong signal that identity proof alone is not enough to constrain access safely. The broader security direction is also consistent with the NIST Cybersecurity Framework 2.0, which treats access governance as an operational control function, not just an authentication feature.

In practice, many security teams discover that the IdP is still “working” long after the authorization model has become the real source of risk, usually only after a policy exception, outage, or audit finding forces the issue.

How It Works in Practice

Separating authorization from the IdP means using the IdP for authentication, user or workload attributes, and basic lifecycle events, while placing access decisions in a dedicated policy layer. That policy layer may sit in an application, API gateway, service mesh, sidecar, or centralized policy engine. The important point is that access rules are evaluated independently from login, so permissions can change without reworking identity plumbing.

For most teams, the practical pattern is: authenticate at the IdP, issue a token or assertion with identity claims, then evaluate authorization at request time using context such as role, resource, action, device posture, time, tenant, or workload trust level. This is where policy-as-code becomes useful. The policy can be versioned, tested, reviewed, and deployed separately from the IdP configuration. That makes access control easier to audit and safer to change.

This separation also helps when different services need different interpretations of the same identity. A finance API may allow read-only access during business hours, while a deployment system may require step-up approval or time-bound elevation. If the IdP is also acting as the policy engine, those rules tend to become duplicated in app code or hidden in directory group sprawl. If you are formalising NHI governance, the Ultimate Guide to NHIs is useful for framing how privilege, rotation, and visibility intersect across the lifecycle.

• Use the IdP for trust establishment, not for encoding every resource rule.
• Centralize authorization logic where possible so decisions are consistent across apps.
• Make policies explicit and testable instead of embedding them in scattered application code.
• Log both the identity proof and the authorization decision for audit and forensics.

This guidance tends to break down in legacy monoliths, tightly coupled SaaS integrations, and environments where the IdP exposes only coarse group membership, because there is no clean request-time policy hook to evaluate context independently.

Common Variations and Edge Cases

Tighter separation often improves governance, but it also increases integration overhead, so teams have to balance control quality against implementation complexity. There is no universal standard for this yet, and current guidance suggests starting with the highest-risk paths first rather than refactoring every entitlement at once.

Some environments do not need a fully centralized authorization service. Small internal tools, low-risk dashboards, or vendor platforms with fixed RBAC may remain adequately managed inside the IdP for now. The tipping point is usually not scale alone, but policy diversity: once different teams, services, or tenants need different conditions for the same identity, the IdP becomes a bottleneck. That is especially true for service accounts, machine identities, and API-driven workloads where entitlement changes must be fast and traceable.

In practice, the cleanest boundary is often: the IdP answers “who are you,” and an external policy layer answers “may you do this now.” For organizations trying to reduce privilege sprawl, that distinction is a practical control boundary, not just an architectural preference. The NIST framing for access governance and the NHI lifecycle both support this split, because it makes review, revocation, and exception handling much more reliable over time.

Related resources from NHI Mgmt Group

• How do you know if dispatch is helping authorization performance?
• Should organisations treat authorization as infrastructure?
• What do teams get wrong about IdP-native roles and policies?
• How do IAM teams know if their identity fabric is actually working?