The Scalability Dilemma of JWT and OAuth 2.0: How the GNAP Protocol Breaks Through

Modern authentication systems almost inevitably hit the same two walls during scaling. Whether you choose JWT or OAuth 2.0, once traffic and security demands reach a certain threshold, the architectural flaws of each approach become glaringly apparent. This article takes a deep dive into the failure modes of these two mainstream approaches and introduces a new protocol based on asymmetric keys — GNAP (RFC 9635) — that fundamentally redesigns the authorization model.

JWT's Scalability Trap: The Cost of Statelessness

JWT (JSON Web Token) looks perfect on paper: stateless, self-contained, and fast to verify. The server doesn't need to store sessions — just verify the signature to confirm the token's validity. This makes it the darling of microservices and distributed architectures.

To understand why JWT is so popular, you first need to understand its technical structure. A JWT consists of three parts: the Header (declaring the signing algorithm), the Payload (carrying user identity and permission claims), and the Signature (a digital signature over the first two parts). Common signing algorithms include HS256 for symmetric keys and RS256/ES256 for asymmetric keys. In microservices architectures, asymmetric signing is particularly important — the authorization server signs tokens with a private key, and each microservice only needs the public key to independently verify them, without sharing secrets. The JWKS (JSON Web Key Set) endpoint is the standard mechanism for distributing these public keys. "Stateless" means the server doesn't need to maintain session storage (unlike the traditional Session-Cookie model, which requires storing session data server-side). Each request carries its own complete identity credentials, making it naturally suited for horizontal scaling.

However, the problem lies precisely in that "stateless" selling point. In real production environments, the moment you need instant token revocation, forced logout, permission changes, or need to respond to a stolen token, JWT's model collapses. Because once a token is issued, it remains valid until expiration — the server has absolutely no way to proactively invalidate it.

To solve this, engineers are forced to introduce a denylist, typically maintained in Redis or a database to track revoked tokens. But this means every request requires an additional denylist lookup, completely defeating the purpose of being "stateless." Worse still, signature malleability vulnerabilities and JWKS cache-miss flooding introduce additional operational and security risks.

Specifically, signature malleability refers to an attacker modifying the binary representation of a signature without invalidating it. In certain algorithm implementations (such as non-normalized s-values in ECDSA), a single message can correspond to multiple valid signatures, which could be exploited to bypass denylist matching based on signature values. JWKS cache-miss flooding is another subtle but highly destructive threat: when a resource server discovers that a JWT's kid (Key ID) isn't in its local JWKS cache, it proactively issues a request to the authorization server's JWKS endpoint. An attacker can forge large volumes of invalid JWTs with different kid values, forcing every request to trigger a remote JWKS fetch, effectively launching a distributed denial-of-service attack against the authorization server. These are among the most common pain points in today's high-concurrency authentication systems.

OAuth 2.0 Token Introspection: The Performance Bottleneck Behind Real-Time Revocation

In contrast to JWT, OAuth 2.0's opaque token approach achieves real-time revocation through token introspection. Every time a resource server receives a token, it queries the authorization server to confirm whether the token is currently valid.

Token introspection is defined by RFC 7662 and is a standard extension in the OAuth 2.0 ecosystem. The workflow is: the resource server sends the received opaque token via a POST request to the authorization server's /introspect endpoint. The authorization server queries its own token store and returns a JSON response containing an active field (a boolean indicating whether the token is valid) along with metadata like scope, exp, and sub. "Opaque token" means the token itself is just a random string identifier containing no parseable payload information — all semantics are stored on the authorization server side. This stands in stark contrast to JWT's "self-contained" model.

This approach does solve the revocation problem, but the cost is equally steep: every protected API request incurs an additional network round-trip to the authorization server. In low-traffic scenarios, this overhead is barely noticeable. But under high throughput, the introspection endpoint quickly becomes a shared bottleneck — connection pools get saturated, and the entire authentication system's p99 latency becomes hostage to the authorization server's latency. Here, p99 latency refers to the 99th percentile latency — meaning 99% of requests complete within this time. It's a key metric for measuring tail latency. When the introspection endpoint becomes a bottleneck, it directly inflates the system's tail latency, severely impacting user experience and SLA guarantees.

Additionally, OAuth 2.0's classic front-channel redirect flow creates noticeable friction for native apps, CLI tools, desktop applications, and even autonomous agents. In OAuth 2.0's classic authorization code flow, "front channel" refers to 302 redirect hops through the user's browser — the user is directed to the authorization server's login page and, after authenticating, is redirected back to the client application with an authorization code. This flow inherently depends on browser URL redirects and cookie mechanisms. For native mobile apps, although it can be simulated through system browsers or custom URL schemes, the experience feels disjointed. For CLI tools and background services, this interaction model is even more awkward. "Back channel," on the other hand, is completed entirely between servers via HTTP API calls, requiring no browser redirects from the user.

In short, JWT and OAuth 2.0 cover the vast majority of authentication systems in production environments, and each has its own way of breaking down under different types of load.

The GNAP Protocol: Reconstructing the Authorization Model with Key-Bound Tokens

GNAP (Grant Negotiation and Authorization Protocol, RFC 9635) takes the approach of redesigning the entire authorization model around asymmetric key-bound tokens.

Core Mechanism: Zero Network Calls Through Local Signature Verification

The key innovation of GNAP is that the client must prove possession of the corresponding private key (typically Ed25519) on every request through HTTP Message Signatures. The resource server only needs to complete signature verification locally — a process that takes just tens of microseconds — with no database queries and no network calls for the token itself.

Ed25519 is a digital signature algorithm based on the Curve25519 elliptic curve, designed by Daniel J. Bernstein and others. It's renowned for its extremely fast signing and verification speeds, fixed 64-byte signature length, and natural resistance to timing attacks. On modern hardware, Ed25519 verification typically takes only tens of microseconds, far faster than the hundreds of microseconds required for RSA-2048. HTTP Message Signatures (RFC 9421) is a separate IETF standard that defines how to digitally sign specific components of an HTTP request (including the method, path, header fields, request body digest, etc.). GNAP leverages this mechanism by requiring clients to sign key HTTP elements with each request. This allows the resource server not only to verify the token's legitimacy but also to confirm that the entity making the request actually holds the corresponding private key — cryptographically binding the token to a specific client instance so that even if the token is intercepted, it cannot be replayed by a third party.

This yields several direct benefits:

• Extremely fast and fully local verification: The overhead on the normal request path is minimized, with no dependency on the availability or latency of external services.
• Tokens remain manageable and revocable: Control over tokens is still possible when needed, but this falls on the exceptional path and doesn't impact day-to-day performance.
• No more browser redirects: The interaction can be completed entirely through the back channel, removing the forced browser redirect constraint for the many non-web clients. GNAP natively supports back-channel interaction at the protocol level, enabling IoT devices, autonomous AI agents, CLI tools, and other non-browser clients to complete authorization in a natural way.

How GNAP Differs from DPoP Proof-of-Possession

It's worth noting that the industry has previously attempted to solve similar problems with "proof-of-possession" mechanisms like DPoP (Demonstration of Proof-of-Possession). DPoP (RFC 9449) is an extension mechanism designed for OAuth 2.0, aimed at binding access tokens to a specific client's key pair. It works by having the client generate a short-lived DPoP Proof JWT for each request, containing the request method, URI, and timestamp, signed with the client's private key and attached in the request header. The authorization server records the client's public key fingerprint when issuing tokens, and the resource server must verify both the access token and the DPoP proof.

However, DPoP is essentially a "patch" on the OAuth 2.0 framework — it's layered on top of the existing Bearer token system, and the token issuance, introspection, and refresh flows still follow OAuth 2.0's original design. GNAP goes further by making key binding a first-class citizen from the ground up. Authorization negotiation, token issuance, and token usage all revolve around asymmetric keys, forming a more concise and consistent security model rather than incremental patches on an existing system.

Practical Selection and Gradual Migration Strategies

There is no silver bullet. While GNAP has clear advantages in its performance and security model, as a relatively new protocol, its ecosystem maturity, library support, and team learning curve are all real factors to weigh.

The original post author also emphasizes that their technical breakdown not only compares JWT, OAuth 2.0, and GNAP across nine security attack vectors, but also demonstrates real verification overhead and memory behavior under high RPS (requests per second), and provides a gradual coexistence and migration path — a particularly pragmatic point. For existing systems, aggressive full-scale replacement is often infeasible; allowing old and new protocols to coexist and migrating incrementally is the approach that actually works in practice.

For teams today, several typical practical choices include:

• Short-lived JWTs + denylist: Sacrifice some statelessness in exchange for revocation capability.
• Opaque tokens + aggressive introspection caching: Use caching to mitigate the introspection bottleneck, but accept some revocation delay.
• Experiment with proof-of-possession mechanisms (DPoP / key-bound tokens): Move toward GNAP's direction.

Conclusion

JWT's "statelessness" and OAuth 2.0's "real-time revocation" are essentially two ends of the same trade-off — it's hard to have both peak performance and instant control. GNAP, through key binding and local signature verification, attempts to break this either-or dilemma: keeping the normal path extremely cheap and local while retaining management capabilities when needed.

For engineering teams struggling with authentication scalability challenges, GNAP offers at least a new direction worth serious evaluation. Of course, any architectural decision should be based on your actual load characteristics, security requirements, and operational capabilities.