What is the difference between authenticating users in the identity provider and authorizing them in the gateway versus using the identity provider for both?

In the split model, the identity provider handles login but the gateway stores local consumers or groups and makes its own authorization decisions. In the centralized model, the identity provider issues the token and carries the entitlement data, while the gateway enforces access from those claims. The second approach reduces duplication, simplifies operations, and makes revocation more consistent.

Why the Split Model and the Centralized Model Produce Different Security Boundaries

The practical difference is where authorization truth lives. In the split model, the identity provider proves who the user is, but the gateway still maintains its own local view of consumers, groups, or policies and decides what the user can do. In the centralized model, the gateway relies on claims from the identity provider, so entitlement changes are managed in one place instead of duplicated across systems.

That boundary change affects more than administration. It changes how quickly access can be revoked, how much policy drift can accumulate, and whether the gateway can make the same decision everywhere it is deployed. If the gateway owns local authorization state, the organization must keep that state synchronized with the identity provider or accept the risk of inconsistent access decisions.

For the identity side of the model, the relevant design question is not just “can the user log in?” but “where is the entitlement source of truth?” That is why centralization usually simplifies audits and lifecycle operations, while split enforcement can still be useful when the gateway needs local independence, coarse caching, or environment-specific policy boundaries.

How Token Claims Change the Authorization Decision

When the identity provider carries entitlement data, the token becomes more than a login artifact. The gateway reads claims such as group membership, role, tenant, or scope and uses them to decide access in real time. That makes the identity provider part of the authorization architecture, not just the authentication step.

By contrast, when the gateway stores local consumers or groups, the token only proves identity and the gateway translates that identity into a local authorization record. This can work well, but it creates a second policy layer that must be governed separately. The more local mappings you maintain, the more likely you are to create exceptions, stale groups, and revocation lag.

This is the reason many teams prefer the centralized pattern for modern federated access. It reduces duplication, but it also makes the claims model important: the identity provider must emit the right entitlements, the gateway must trust the right issuer, and token contents must be kept tight enough to avoid overexposing privileges.

Operational Trade-offs Between Local Control and Centralized Entitlements

The split model gives the gateway autonomy. That can help when the gateway needs to operate with partial independence from the identity provider, when a business unit wants local policy control, or when an integration only supports local consumer records. The cost is extra lifecycle work, because every change in entitlement may need to be mirrored in more than one place.

The centralized model is usually cleaner for ongoing operations because it removes duplicate role management and makes revocation more consistent. It also improves onboarding and offboarding, since access decisions track the identity provider’s current state instead of a separately maintained gateway roster. The trade-off is that the identity provider becomes more critical, because mistakes in claims or trust configuration can affect every downstream enforcement point at once.

In practice, the right model often depends on whether the gateway is acting as a policy consumer or a policy owner. If the gateway is just enforcing access at the edge, centralized entitlements usually win. If the gateway needs to preserve local business rules or disconnected operation, split authorization can be justified, but only with strong synchronization discipline.

Risk and Threat Considerations

The main security risk in the split model is policy drift: a user may still be able to pass the identity provider even after the gateway’s local authorization data has become stale. The centralized model reduces that drift, but it also concentrates trust in the token and the entitlement claims, so a compromise of claims, issuer trust, or token handling can have broad impact.

Failure mechanism: In the split model, revocation and role changes can lag because local gateway mappings do not update at the same speed as the identity provider. In the centralized model, overly broad claims, weak issuer validation, or token reuse can cause the gateway to accept access that no longer reflects the intended entitlement state.

Impact: Stale local authorization can leave users with access after they should have lost it, while centralized claim-based authorization can propagate a bad entitlement decision quickly across multiple gateways. The difference is whether the main failure mode is inconsistency or concentration.

Standards & Framework Alignment

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

NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	This question is about federated login and entitlement-based access decisions.
Recommendation — Apply digital identity guidance to separate authentication from authorization and validate token-based trust.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	The split model still depends on the identity provider establishing user identity.
	AC-3 — Access Enforcement	The gateway enforces access based on either local mappings or identity claims.
	AC-6 — Least Privilege	Centralized claims or local groups must both avoid unnecessary access expansion.
Recommendation — Enforce strong organizational-user authentication at the identity provider before gateway access is considered. Implement access enforcement at the gateway using the chosen authorization source of truth. Minimize claims and gateway permissions so users receive only the access they need.
ISO/IEC 27001:2022	A.5.15 — Access control	The question concerns how access decisions are governed across identity provider and gateway.
Recommendation — Define and document a consistent access-control model across the identity provider and gateway.
OWASP ASVS	V8 — Authorization	The gateway decision is an authorization problem driven by authenticated identity claims.
Recommendation — Verify authorization decisions are enforced consistently and cannot be bypassed by stale local records.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The comparison hinges on where trust is verified and how access is continuously enforced.
Recommendation — Use verified identity and least privilege at each enforcement point instead of assuming inherited trust.

Practitioner Guidance

What to verify: Decide where the source of truth for entitlement changes lives, then verify that revocation, group changes, and role changes reach the enforcement point within the time window your risk posture requires. If the gateway still keeps local consumer records, test how long a removed user or group remains effective after the identity provider changes.

Decision rule: If the gateway is only enforcing access, prefer identity-provider claims plus a small, well-defined set of gateway checks. If the gateway must maintain local authorization data, treat synchronization, drift detection, and exception handling as first-class operational controls rather than implementation details.

Practitioner takeaway: The better model is the one that makes authorization state easiest to keep current under real operational pressure, because inconsistent revocation is usually more dangerous than a slightly simpler login flow.