OAuth 2.0 token endpoint latency that only appears under concurrent requests

Direct Answer

RFC 6749 and the OAuth 2.0 Security BCP mandate that authorization codes and rotated refresh tokens be single-use, but they do not prescribe locking or serialization mechanisms. The concurrency-only latency you observe is almost certainly an implementation choice—typically per-user or per-client mutexes during token invalidation, synchronous token introspection calls, unpooled database connections, or blocking JWKS fetches. A refresh token reuse grace window (if your server supports one) reduces contention by avoiding strict single-use races; strict rotation requires atomic compare-and-swap or row locking, which serializes parallel refresh requests for the same principal.

Spec-Mandated Serialization vs. Implementation Choices

• Mandated by spec: Authorization codes must be single-use and short-lived (RFC 6749 §4.1.2). Refresh token rotation is recommended (Security BCP §4.12.2) but not required.
• Implementation choices that cause concurrency latency:
  • Global or per-principal locks when deleting a used code or rotated refresh token.
  • Synchronous introspection (RFC 7662) lookups per request against a shared cache or database.
  • Database row locks, transaction isolation levels, or connection pool exhaustion on token tables.
  • Blocking JWKS HTTP fetches without caching or connection pooling.

Reliable Isolation Method

1. Run a controlled load test against the token endpoint with all downstream dependencies mocked (introspection endpoint, JWKS endpoint, userinfo service, any external user store).
2. Compare latency curves: baseline (mocks) vs. production dependencies. If latency disappears with mocks, the bottleneck is outside OAuth logic.
3. Enable debug logging for token invalidation paths and measure lock wait times or queue lengths via the server's diagnostics (JVM thread dumps, Go pprof, .NET EventCounters).
4. Check database lock statistics during the test: pg_stat_activity (PostgreSQL) or SHOW ENGINE INNODB STATUS (MySQL) for lock waits on token tables.
5. Test with a single client/user vs. multiple distinct clients/users to differentiate per-principal locking from global contention.

Refresh Token Grace Window Impact

A reuse grace window (allowing the old refresh token to remain valid for a short period after rotation) materially reduces contention under parallel refresh requests because it eliminates the race to invalidate the old token atomically. Strict single-use enforcement requires a critical section (row lock or CAS), which serializes concurrent refreshes for the same user/client. However, grace windows increase replay risk and are not standardized—some servers expose them via configuration (e.g., "reuse interval"), others not at all. Verify your server's documentation and current configuration before assuming a grace window exists.

One Diagnostic Detail Needed

What is the exact authorization server product and version (e.g., Keycloak 24.0, Auth0, Spring Authorization Server 1.2, IdentityServer 8)? Locking behavior, cache eviction policies, and grace window defaults are implementation-specific and change the recommended mitigation.