invalid_grant error in refresh token endpoint leading to memory leak

Confirmed facts

When an authorization server returns invalid_grant for a refresh‑token request, many implementations keep the refresh‑token object (or a wrapper such as RefreshTokenHolder) in an in‑memory token store or request‑scoped cache until the thread finishes. If the error‑handling path does not evict that entry, each failed refresh leaves a live reference, causing heap usage to grow linearly with the rate of bad requests.

Likely explanation

The leak is not caused by the rotation policy itself; it stems from missing cleanup in the error branch. Adding rotation does not increase the leak risk as long as the same cleanup runs for both success and failure.

Steps to add to the invalid_grant path

1. Evict the refresh‑token entry from the token store (e.g., tokenStore.remove(refreshToken) for a Map or ConcurrentHashMap).
2. If the store uses soft references or wrappers, clear the wrapper so the underlying object becomes eligible for GC.
3. Release any request‑scoped objects attached to the current thread or servlet request (e.g., clear ThreadLocal values, remove request attributes, close short‑lived DB connections or Hibernate sessions opened for token validation).
4. Ensure the cleanup runs in a finally block or via a filter/interceptor that guarantees execution regardless of the response outcome.

Does compulsory rotation amplify the leak?

Only if the error path still omits the eviction step. With proper cleanup, each rotation attempt—whether successful or resulting in invalid_grant—leaves no residual reference, so the leak does not grow.

Verification approach

• Enable heap profiling (e.g., JDK Flight Recorder or VisualVM) before and after a burst of invalid‑grant refresh requests; confirm that instances of RefreshTokenHolder or similar do not accumulate.
• Add a log statement in the token store’s remove method and verify a log line appears for every invalid_grant response during a test run.
• Run a load test with a high ratio of bad refresh tokens (e.g., 90 % invalid) and observe that heap usage stabilizes over time; measure average token‑endpoint latency to ensure no regression.
• Test with legacy clients that still send non‑rotated tokens to confirm they receive the expected error without side effects.

Missing diagnostic detail

To tailor the eviction step, please confirm: Is your token store an in‑memory cache (e.g., ConcurrentHashMap) or a persistent store backed by a database?