API gateways play a central role in modern architectures — they manage routing, enforce rate limits, handle protocol translation, and provide a consistent entry point for backend services. As systems grow, it’s easy to start relying on the gateway for more than just transport and routing, but also for handling authentication and access.

That’s where things often go wrong.

API gateways are sometimes used to validate tokens, parse user claims, manage login redirects, and even make authorization decisions. It might seem efficient to bundle all of this in one place — fewer moving parts, tighter control. But in reality, pushing identity logic into the gateway tends to backfire. It adds complexity, limits flexibility, and can quietly introduce security issues that are tough to catch and even harder to fix.

This article explores why it’s essential to handle identity outside the gateway, using a purpose-built identity provider, and how a clean separation of responsibilities leads to more secure and maintainable API infrastructure.

What API Gateways Do Well

API gateways are good at handling traffic. They route requests, enforce rate limits, and take care of protocol and connection details, but they are not built to manage identity.

Core responsibilities typically include:

• Routing requests to the right backend service
• Rate limiting and brute force protection
• Caching to reduce backend load
• TLS termination and protocol translation
• Logging and observability for monitoring traffic
• Request/response transformation for adapting formats

These functions are stateless and infrastructure-focused. Gateways excel at these tasks, but as we’ll see next, they’re not equipped to handle the full complexity of identity and access management.

When Gateways Take On Too Much

As API gateways have grown in capability, many teams have started to rely on them for more than just transport and routing. It’s not uncommon to see identity-related responsibilities pushed onto the gateway, either for convenience or due to architectural shortcuts.

Here are some of the identity tasks often delegated to gateways:

• Token validation: Verifying the structure, signature, and expiration of JWTs.
• Authorization enforcement: Making access decisions based on request details, claims, and scopes in the token.
• OAuth and OpenID Connect handling: Implementing the protocols on behalf of the clients, such as redirecting users to log in, exchanging authorization codes for tokens, or managing session state.
• Federation logic: Connecting with upstream identity providers for SSO or social login.
• Claims processing: Extracting or transforming claims to enrich requests before forwarding them downstream.

While many gateways offer plugins or extensions for identity-focused tasks, treating the gateway as a full identity layer creates long-term challenges. Gateways are often tightly coupled to specific token formats or protocols, which makes it difficult to adapt when identity requirements change.

In short, the more identity logic the gateway takes on, the more it drifts from its core purpose, and the harder it becomes to adapt, debug, or secure the overall system.

Where Gateway-Based Identity Fails

Using the API gateway to handle identity may seem convenient at first, especially in smaller setups. But as systems grow and complexity increases, limitations become apparent. It’s important to remember that identity management is a specialized function, and API gateways are not designed for it.

Here are some of the problems that tend to arise:

Overcomplicated Token Validation

When using JWTs as access tokens, gateways typically validate token signatures and expiration but tend to miss important context. For example, they might not check whether a token was revoked, whether scopes have timed out, or whether a user session is still active. Without access to real-time introspection or policy decisions, access control becomes unreliable.

Scattered Authorization Logic

When access decisions are made at the gateway level, logic often gets duplicated across routes or services, which can lead to inconsistencies, make testing more difficult, and create unclear access rules that are hard to maintain or audit.

Rigid Support for Federation and Advanced Flows

Scenarios like federated login, token exchange, or delegated authorization require coordination with upstream identity providers and session management. Gateways typically can’t support these flows fully or flexibly, which limits your ability to evolve authentication and authorization models over time.

Tight Coupling of Concerns

Combining transport logic with identity management reduces flexibility. If you need to change identity providers and token formats or introduce new authentication factors, changes to gateway behavior can affect the stability of the entire API layer.

Poor Observability and Troubleshooting

When identity logic is buried in gateway configuration, identifying issues becomes more difficult. It’s often unclear whether a failure is due to routing rules, claim mismatches, or upstream identity errors. It can slow down debugging and complicate operations.

Delegating identity to the gateway may simplify the short term, but it tends to create long-term risks in performance, security, and maintainability. The better approach is to offload identity to a dedicated service, allowing the gateway to focus on what it does best.

Delegating Identity for Better Scalability

Instead of making the API gateway responsible for identity, a more reliable approach is to delegate that responsibility to an identity provider. This creates a clear separation between transport and security logic.

In this model, an OAuth or OpenID Connect server handles authentication, token issuance, and user attribute collection. The gateway simply enforces policies based on the information received in the token. It checks tokens and applies access rules but doesn’t manage login flows, sessions, or federation. Here are some advantages:

• Identity logic is centralized and easier to manage
• Use cases like federated login or multi-factor authentication are easier to support
• Token validation is more reliable, using introspection or structured claims
• Gateway configuration stays focused and maintainable

For example, rather than the gateway interpreting a token directly, it can call the identity provider’s introspection endpoint to verify the validity of the token and enforce a minimal coarse-grained access policy. This keeps the gateway lightweight and ensures access decisions reflect the current user context and policy.

By separating these concerns, systems become easier to scale, adapt, and secure.

Implementation Patterns for Delegation

Delegating identity means applying the right integration patterns to keep identity handling centralized and secure while allowing the gateway to enforce access effectively. Below are several approaches that support this architecture.

Token Introspection

With opaque tokens, the gateway doesn’t validate the token directly. Instead, it sends the token to the identity provider’s introspection endpoint to retrieve its status, scopes, and claims. Ensuring validation is consistent and up-to-date. It’s a simple and effective way to separate enforcement from decision-making while avoiding token parsing at the gateway.

Phantom Token Pattern

In this model, the client receives an opaque access token. When the gateway receives a request, it exchanges the opaque token for a JWT access token by calling a token endpoint at the identity provider and passes along the JWT with the request.

Key benefits of this pattern include:

• Hides internal claims and token structure from clients
• Enables opaque tokens externally and JWTs internally
• Reduces gateway complexity by avoiding token parsing
• Creates an internal token that is not usable from the outside
• Enables the gateway to perform a coarse-grained authorization, and the API can perform a fine-grained authorization based on the JWT received

The Phantom Token approach is ideal when you want clients to use access tokens without being able to inspect or misuse their contents.

Split Token Pattern

The Split Token pattern is a variant of the Phantom Token pattern, better suited for distributed gateways and APIs that require low latency. It has similar benefits to the Phantom Token in that the client receives an opaque token, but the API gets a JWT. The difference would be that the OAuth server issues a signed JWT and gives the signature part to the client to be used as the access token. The OAuth server then sends the header and payload part along with a hashed version of the signature to the gateway. This means that the gateway can construct a JWT out of the token it receives from a client in an API request without having the full token already available.

Advantages of this approach:

• Strong token security: The gateway does not have the full token, meaning an attacker can not obtain a token to be used with the API by attacking the gateway.
• Fewer network calls for token validation: The gateway looks up the token in its cache instead of making a callout to an OAuth server.
• Improved multi-region support: The OAuth server can push the split token to caches available to all the distributed gateways.

Backend-for-Frontend (BFF) Pattern

In web applications, it’s common to use a backend component that handles all identity interactions with the identity provider. Tokens are stored and used only on the server side, while the frontend communicates with the backend over a secure session. The API gateway simply routes requests, without dealing with tokens directly, keeping the frontend free from identity logic and reducing the risk of token leakage.

One example of this pattern is Curity’s Token Handler, which provides a structured way to manage tokens for single-page applications using a secure backend component. This component handles the translation of the secure session into tokens so that the API can treat the requests in the same way as for the other patterns.

Each of these patterns supports the same goal: move identity management to a trusted provider and keep the gateway focused on enforcement. Choosing the correct pattern depends on your architecture, risk profile, and client types.

Final Thoughts

API gateways are excellent at managing traffic and enforcing access policies. But they aren’t designed to handle identity. Trying to fit authentication and authorization into the gateway often leads to complexity, inconsistency, and security gaps.

Offloading identity to a dedicated provider keeps the architecture clean. The gateway stays focused on routing and enforcement. The identity system handles authentication, tokens, and access decisions.

This separation isn’t just nice to have — it’s necessary if you want to scale securely and keep the system maintainable over time.