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.
62 lines
2.3 KiB
Markdown
62 lines
2.3 KiB
Markdown
[← 06 Resource server](06-resource-server.md) · [index](README.md) · next: [08 — The relying party](08-client.md)
|
|
|
|
# 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`](../../authorization-server/auth-server/src/main/java/com/ankurm/authserver/diag/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`](../output/as-discovery.txt)):
|
|
|
|
```json
|
|
{
|
|
"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`](../02-filter-chain-and-ordering.md).
|
|
|
|
## The `trace` profile
|
|
|
|
```bash
|
|
./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](08-client.md)
|