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
161 lines
5.9 KiB
Plaintext
161 lines
5.9 KiB
Plaintext
--------------------------------------------------------------------------
|
|
resource server profiles: stub,roles,audience,attyp
|
|
--------------------------------------------------------------------------
|
|
--------------------------------------------------------------------------
|
|
1. A correct token
|
|
--------------------------------------------------------------------------
|
|
header: {"kid": "stub-key-1", "typ": "JWT", "alg": "RS256"}
|
|
iss "http://localhost:9000"
|
|
aud "reports-api"
|
|
scope "profile:read reports:read"
|
|
preferred_username "alice"
|
|
realm_access {"roles": ["USER"]}
|
|
resource_access {"reports-api": {"roles": ["reports-reader"]}}
|
|
|
|
$ GET /api/me
|
|
HTTP 200
|
|
{
|
|
"name": "alice",
|
|
"authorities": [
|
|
"FACTOR_BEARER",
|
|
"ROLE_USER",
|
|
"ROLE_reports-reader",
|
|
"SCOPE_profile:read",
|
|
"SCOPE_reports:read"
|
|
],
|
|
"iss": "http://localhost:9000",
|
|
"aud": [
|
|
"reports-api"
|
|
],
|
|
"typ": "JWT",
|
|
"kid": "stub-key-1",
|
|
"exp": "2026-08-23T10:32:56Z"
|
|
}
|
|
|
|
--------------------------------------------------------------------------
|
|
2. Signed by the right key, but iss says something else
|
|
--------------------------------------------------------------------------
|
|
The signature verifies. The key is the same key. Only the string differs.
|
|
header: {"kid": "stub-key-1", "typ": "JWT", "alg": "RS256"}
|
|
iss "http://localhost:9000/other"
|
|
aud "reports-api"
|
|
scope "profile:read reports:read"
|
|
preferred_username "alice"
|
|
realm_access {"roles": ["USER"]}
|
|
resource_access {"reports-api": {"roles": ["reports-reader"]}}
|
|
|
|
$ GET /api/me
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: The iss claim is not valid", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|
|
--------------------------------------------------------------------------
|
|
3. A token minted for a different service in the same realm
|
|
--------------------------------------------------------------------------
|
|
This is the one that silently works when nothing checks aud.
|
|
header: {"kid": "stub-key-1", "typ": "JWT", "alg": "RS256"}
|
|
iss "http://localhost:9000"
|
|
aud "billing-api"
|
|
scope "profile:read reports:read"
|
|
preferred_username "alice"
|
|
realm_access {"roles": ["USER"]}
|
|
resource_access {"reports-api": {"roles": ["reports-reader"]}}
|
|
|
|
$ GET /api/me
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: The aud claim is not valid", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|
|
--------------------------------------------------------------------------
|
|
4. Expired 90 seconds ago
|
|
--------------------------------------------------------------------------
|
|
The default clock skew is 60s, so a token has to be more than a minute stale
|
|
before JwtTimestampValidator refuses it.
|
|
|
|
$ GET /api/me
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: Jwt expired at 2026-08-23T10:26:26Z", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|
|
--------------------------------------------------------------------------
|
|
5. Expired 30 seconds ago - inside the default clock skew
|
|
--------------------------------------------------------------------------
|
|
|
|
$ GET /api/me
|
|
HTTP 200
|
|
{
|
|
"name": "alice",
|
|
"authorities": [
|
|
"FACTOR_BEARER",
|
|
"ROLE_USER",
|
|
"ROLE_reports-reader",
|
|
"SCOPE_profile:read",
|
|
"SCOPE_reports:read"
|
|
],
|
|
"iss": "http://localhost:9000",
|
|
"aud": [
|
|
"reports-api"
|
|
],
|
|
"typ": "JWT",
|
|
"kid": "stub-key-1",
|
|
"exp": "2026-08-23T10:27:26Z"
|
|
}
|
|
|
|
--------------------------------------------------------------------------
|
|
6. typ=at+jwt, which RFC 9068 says an access token SHOULD carry
|
|
--------------------------------------------------------------------------
|
|
The default validator stack contains JwtTypeValidator.jwt(), which accepts only an
|
|
absent typ or typ=JWT. Whether this passes depends on the attyp profile.
|
|
header: {"kid": "stub-key-1", "typ": "at+jwt", "alg": "RS256"}
|
|
iss "http://localhost:9000"
|
|
aud "reports-api"
|
|
scope "profile:read reports:read"
|
|
preferred_username "alice"
|
|
realm_access {"roles": ["USER"]}
|
|
resource_access {"reports-api": {"roles": ["reports-reader"]}}
|
|
|
|
$ GET /api/me
|
|
HTTP 200
|
|
{
|
|
"name": "alice",
|
|
"authorities": [
|
|
"FACTOR_BEARER",
|
|
"ROLE_USER",
|
|
"ROLE_reports-reader",
|
|
"SCOPE_profile:read",
|
|
"SCOPE_reports:read"
|
|
],
|
|
"iss": "http://localhost:9000",
|
|
"aud": [
|
|
"reports-api"
|
|
],
|
|
"typ": "at+jwt",
|
|
"kid": "stub-key-1",
|
|
"exp": "2026-08-23T10:32:56Z"
|
|
}
|
|
|
|
--------------------------------------------------------------------------
|
|
7. No token at all
|
|
--------------------------------------------------------------------------
|
|
|
|
$ GET /api/me
|
|
HTTP 401
|
|
WWW-Authenticate: Bearer resource_metadata="http://localhost:8081/.well-known/oauth-protected-resource"
|
|
|
|
$ GET /api/public/ping
|
|
HTTP 200
|
|
{
|
|
"status": "up"
|
|
}
|
|
|
|
--------------------------------------------------------------------------
|
|
8. The endpoint nobody configured
|
|
--------------------------------------------------------------------------
|
|
Spring Security 7 publishes RFC 9728 protected resource metadata and points the
|
|
WWW-Authenticate challenge at it. It answers without a token.
|
|
|
|
$ GET /.well-known/oauth-protected-resource
|
|
HTTP 200
|
|
{
|
|
"resource": "http://localhost:8081",
|
|
"bearer_methods_supported": [
|
|
"header"
|
|
],
|
|
"tls_client_certificate_bound_access_tokens": true
|
|
}
|
|
|