OAuth 2.0 token endpoint latency that only appears under concurrent requests

Symptom

An OAuth 2.0 authorization server implementing the Authorization Code Grant with PKCE shows acceptable token endpoint latency for sequential requests, but latency rises noticeably once multiple clients exchange codes or refresh tokens in parallel. Single-request benchmarks look normal, so the slowdown only surfaces under concurrency.

Context and constraints

RFC 6749 requires authorization codes to be short-lived and single-use, and OAuth 2.0 Security Best Current Practice recommends refresh token rotation, but neither mandates how an implementation achieves atomicity. Many servers serialize token issuance per client or user, or take locks when invalidating a used code or rotated refresh token. Token introspection (RFC 7662) can add a backend lookup per request. Latency could also come from outside OAuth entirely, such as database contention or JWKS fetching, so the token endpoint needs to be isolated before attributing the cause.

Assume a current mainstream authorization server version; exact locking, caching, and rotation grace-window behavior is implementation specific and should be verified against the server's documentation.

Questions

• Which parts of the code exchange and refresh token rotation paths are specified to require serialization, and which are implementation choices that could explain concurrency-only latency?
• What is a reliable way to isolate whether the slowdown comes from token invalidation locking, introspection lookups, or non-OAuth infrastructure?
• Does choosing a refresh token reuse grace window versus strict single-use materially change contention under parallel refresh requests?