Ankur Mhatre
e9381dc5be
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.
43 lines
2.3 KiB
Plaintext
43 lines
2.3 KiB
Plaintext
|
|
------------------------------------------------------------------
|
|
== PKCE parameters (RFC 7636)
|
|
------------------------------------------------------------------
|
|
code_verifier BTbNq-KzR5R5zjPoT5s8JVMvvweKRQq_dMcGF-2P7Ea8-lku7Jgv0Na6RZkxBjlY (64 chars)
|
|
code_challenge B_BI3Dk68d1epKthalJJxOKFAN0mf3FkUOoJRuV26kM
|
|
code_challenge_method S256
|
|
|
|
The verifier never leaves the client until the token request. The challenge is
|
|
all the authorization request carries, and it is a one-way hash of the verifier.
|
|
|
|
------------------------------------------------------------------
|
|
== 1. Log in to the authorization server (browser session)
|
|
------------------------------------------------------------------
|
|
$ curl -c jar -d username=alice -d password=password -d _csrf=<token> http://localhost:9000/login
|
|
HTTP/1.1 302
|
|
Location: http://localhost:9000/
|
|
|
|
------------------------------------------------------------------
|
|
== 2. GET /oauth2/authorize (client=demo-spa)
|
|
------------------------------------------------------------------
|
|
NO_CHALLENGE=1: the authorization request carries no code_challenge.
|
|
|
|
$ curl -b jar 'http://localhost:9000/oauth2/authorize?response_type=code&client_id=demo-spa&redirect_uri=http%3A%2F%2F127.0.0.1%3A8080%2Fauthorized&scope=openid%20orders.read&state=xyz123'
|
|
-> 302 http://127.0.0.1:8080/authorized?error=invalid_request&error_description=OAuth%202.0%20Parameter%3A%20code_challenge&error_uri=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7636%23section-4.4.1&state=xyz123
|
|
|
|
------------------------------------------------------------------
|
|
== 3. No consent page
|
|
------------------------------------------------------------------
|
|
The authorization endpoint went straight back to the client. Either consent is
|
|
off for this client, or every requested scope was already approved.
|
|
|
|
------------------------------------------------------------------
|
|
== 5. The authorization code
|
|
------------------------------------------------------------------
|
|
code =
|
|
state = xyz123 (the client's own value, returned untouched - compare it)
|
|
no code in the redirect. The error was:
|
|
http://127.0.0.1:8080/authorized?error=invalid_request
|
|
error_description=OAuth%202.0%20Parameter%3A%20code_challenge
|
|
error_uri=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7636%23section-4.4.1
|
|
state=xyz123
|