Ankur Mhatre
4dc45d5e00
Companion code for the follow-up article. The repository now holds two Maven
projects sharing one docs/ tree:
jwt-authentication/ the hand-written filter application (unchanged, moved)
oauth2-resource-server/ a resource server, a Keycloak compose, and a stub
issuer whose JWK Set can be mutated on command
The stub exists because Keycloak will not rotate a signing key at a chosen
second, report how many times its JWKS endpoint was fetched, or drop a key from
the published set on request - and the caching and rotation measurements need
all three. The Keycloak run confirms the same code path against a real issuer.
Findings captured under docs/output/, all from real runs:
* The default validator stack does not check aud. A token minted for another
service in the same realm is accepted.
* Spring Security builds its JWKSource with refreshAheadCache(false) and
rateLimited(false), overriding two of Nimbus's protective defaults, and
enables Nimbus caching only when NO Spring cache was supplied - so
supplying one removes the five-minute expiry.
* A key retired from the JWK Set stops being accepted at t+300s with the
default cache, and never with a Spring cache that has no TTL.
* 25 tokens carrying an unknown kid produce 25 JWKS fetches at the issuer,
through permitAll() endpoints included.
* A hyphenated client id in an authorities-claim-expression parses as
subtraction; the SpelEvaluationException is swallowed and logged at TRACE.
* A clientScopes key in a Keycloak realm import replaces the built-in scopes
rather than adding to them.
New docs chapters 12-18. README covers both projects. Existing docs and scripts
updated for the new paths; no docs/output/ file from the first article moved, so
links in the published article still resolve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013f7f2XZXrQ6gW3RtZE187t
70 lines
2.5 KiB
Plaintext
70 lines
2.5 KiB
Plaintext
--------------------------------------------------------------------------
|
|
resource server profiles: stub,roles,audience
|
|
--------------------------------------------------------------------------
|
|
Issuer state at the start:
|
|
{
|
|
"message": "ok",
|
|
"activeKid": "stub-key-1",
|
|
"publishedKids": [
|
|
"stub-key-1"
|
|
],
|
|
"jwksFetches": 0
|
|
}
|
|
--------------------------------------------------------------------------
|
|
0. Warm the cache
|
|
--------------------------------------------------------------------------
|
|
token signed with stub-key-1
|
|
GET /api/me -> 200
|
|
jwks fetches so far: 1
|
|
--------------------------------------------------------------------------
|
|
1. PUBLISH a second key. Nothing signs with it yet.
|
|
--------------------------------------------------------------------------
|
|
published: stub-key-2
|
|
{
|
|
"message": "ok",
|
|
"activeKid": "stub-key-1",
|
|
"publishedKids": [
|
|
"stub-key-1",
|
|
"stub-key-2"
|
|
],
|
|
"jwksFetches": 1
|
|
}
|
|
|
|
The resource server has not been told. Its cached JWK Set still holds one key.
|
|
Old token still works: 200
|
|
jwks fetches so far: 1 <- unchanged: nothing forced a refresh
|
|
--------------------------------------------------------------------------
|
|
2. ACTIVATE the new key. The issuer starts signing with it.
|
|
--------------------------------------------------------------------------
|
|
A token arrives whose kid is not in the cached JWK Set.
|
|
New token: 200
|
|
jwks fetches so far: 2 <- the unknown kid forced one
|
|
|
|
This is the recovery path, and it works. It is also the only thing in the default
|
|
configuration that notices a rotation, because refresh-ahead is switched off.
|
|
--------------------------------------------------------------------------
|
|
3. Tokens signed with the old key are still in flight
|
|
--------------------------------------------------------------------------
|
|
They were minted before the switch and have not expired yet.
|
|
Old token: 200 <- still accepted, because the old key is still published
|
|
--------------------------------------------------------------------------
|
|
4. RETIRE the old key from the JWK Set
|
|
--------------------------------------------------------------------------
|
|
retired: stub-key-1
|
|
{
|
|
"message": "ok",
|
|
"activeKid": "stub-key-2",
|
|
"publishedKids": [
|
|
"stub-key-2"
|
|
],
|
|
"jwksFetches": 2
|
|
}
|
|
|
|
The resource server's cache still contains it, so nothing changes yet.
|
|
Old token: 200
|
|
New token: 200
|
|
jwks fetches so far: 2
|
|
|
|
How long the old key keeps working from here is decided entirely by the cache.
|
|
See retired-key-demo.sh, which runs this same step under two cache configurations.
|