Guanping Zhang created CXF-9238:
-----------------------------------
Summary: AbstractAccessTokenValidator validation cache evicts ALL
entries via clear() on overflow — replace with LRU to avoid cache-thrash
Key: CXF-9238
URL: https://issues.apache.org/jira/browse/CXF-9238
Project: CXF
Issue Type: Improvement
Components: JAX-RS Security
Affects Versions: 4.2.1
Environment: Apache CXF 4.2.1, Java 11+, OAuth2 resource server with
setMaxValidationDataCacheSize enabled.
Reporter: Guanping Zhang
In AbstractAccessTokenValidator.getAccessTokenValidation() (approx. lines
164-168), the in-memory validation cache (ConcurrentHashMap bounded by
maxValidationDataCacheSize) evicts ALL entries via clear() when the size limit
is reached, instead of an LRU/LFU policy. The code comment acknowledges the gap
("or delete the ones expiring sooner than others, etc.").
Consequence: presenting maxValidationDataCacheSize+1 distinct tokens empties
the entire cache, so every subsequent request requires a full re-validation
(introspection round-trip or signature/claims re-check). A sustained stream of
fresh tokens keeps the cache permanently cold, amplifying load on the
authorization server and degrading resource-server throughput (cache-thrash /
uncontrolled resource consumption, CWE-400).
Scope note: this applies only when the validation cache is enabled
(setMaxValidationDataCacheSize > 0). It is a performance/availability hardening
issue, not a security-boundary bypass (the cached-decision freshness concern is
tracked separately).
Suggested improvement: replace clear() with bounded LRU eviction (e.g.
LinkedHashMap with removeEldestEntry, or a Caffeine/Guava cache with
maximumSize), evicting the least-recently-used entry on overflow rather than
the whole cache.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
