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
35 lines
2.0 KiB
Plaintext
35 lines
2.0 KiB
Plaintext
--------------------------------------------------------------------------
|
|
resource server profiles: stub,roles
|
|
--------------------------------------------------------------------------
|
|
Baseline: 25 requests with a VALID token, whose kid is in the cached JWK Set.
|
|
requests to the resource server : 25
|
|
fetches of /jwks.json : 0
|
|
|
|
Now 25 requests carrying a token whose kid has never existed.
|
|
Each one is refused - but look at what it costs the issuer first.
|
|
requests to the resource server : 25
|
|
fetches of /jwks.json : 25
|
|
|
|
Every rejected request became a request to the authorization server. An attacker who
|
|
can reach an unauthenticated endpoint of your resource server can point that ratio at
|
|
your identity provider, from one connection, using tokens that are never valid.
|
|
|
|
And it does not need an authenticated endpoint. /api/public/ping is permitAll().
|
|
requests to /api/public/ping : 25
|
|
fetches of /jwks.json : 25
|
|
|
|
A permitAll() endpoint still evaluates a bearer token if one is present, because
|
|
BearerTokenAuthenticationFilter runs before any authorization rule. Presenting a
|
|
broken token to a public endpoint gets a 401 from the public endpoint - and a
|
|
JWKS fetch on the way.
|
|
|
|
$ GET /api/public/ping with an unknown kid
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: Signed JWT rejected: Another algorithm expected, or no matching key(s) found", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|
|
|
|
The status returned to the caller is unremarkable:
|
|
|
|
$ GET /api/me with an unknown kid
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: Signed JWT rejected: Another algorithm expected, or no matching key(s) found", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|