Ankur Mhatre
38c0a5f358
Three modules on Spring Boot 4.1.1 with Spring Authorization Server 7.1.1: the provider
itself, a relying party, and an API that trusts its tokens. Client registration, PKCE,
a custom consent page and token customisation, with profiles that make each failure
reproducible.
Every claim is backed by captured output in docs/output/as-*.txt, regenerated by
authorization-server/scripts/run-all.sh. Notable findings, verified against the jars:
- OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(HttpSecurity) was deleted
in 7.0, and both configuration classes moved into spring-security-config
- ClientSettings.requireProofKey flipped from false to true, on the authorization server
(1.5.8 -> 7.1.1) and on the OAuth2 client (6.5.1 -> 7.1.1)
- requireProofKey(false) does not make PKCE optional for a public client; the code
verifier is that client's only authentication at the token endpoint
- MediaTypeRequestMatcher(TEXT_HTML) matches Accept: */*, so the token endpoint answers
API callers with 302 -> /login unless setIgnoredMediaTypes(ALL) is called
Also renames the repository to spring-auth-demo and cross-links the new chapter set from
the existing documentation.
2.3 KiB
← 06 Resource server · index · next: 08 — The relying party
Diagnostics
The interesting configuration in an authorization server is spread across three builders and two filter chains, and the effective result is printed nowhere at startup. Reading the beans back is faster than reasoning about them.
Source:
ProviderDiagnostics.java.
Delete it before shipping — it exposes client ids, scopes, grant types and your
chain ordering to anyone who can reach /diag.
/diag/settings
Every endpoint path the server resolved, including the ones you never configured. Useful when a client insists your token endpoint is somewhere else.
/diag/clients
The registered clients as the server actually holds them. This is where
requireProofKey: true on a client you never configured shows up
(as-discovery.txt):
{
"clientId": "demo-service",
"grantTypes": ["client_credentials"],
"requireProofKey": true,
"requireAuthorizationConsent": false,
"accessTokenFormat": "self-contained",
"accessTokenTtlSeconds": 600,
"reuseRefreshTokens": true
}
The client secret is deliberately not returned. It is a hash, and printing it invites someone to try to use it as a secret.
/diag/chains
The filter chains in the order Spring Security will consult them. If the authorization
server chain is not first, the token endpoint is unreachable, and this is where you see
that rather than inferring it from a 302 to /login. The equivalent for the resource-server
project is docs/02-filter-chain-and-ordering.md.
The trace profile
./scripts/run.sh auth trace
Turns org.springframework.security up to TRACE. Verbose, but it is the only way to see
which AuthenticationProvider handled — or declined — a token request.
Decoding a token without verifying it
scripts/lib.sh has jwt_header and jwt_payload, three lines of base64url each. Debug
only. Never make a decision on an unverified payload; that is the entire attack.
Next: 08 — The relying party