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.
36 lines
2.0 KiB
Plaintext
36 lines
2.0 KiB
Plaintext
|
|
------------------------------------------------------------------
|
|
== The relying party drives the flow [confidential client, no PKCE - the Boot default]
|
|
------------------------------------------------------------------
|
|
GET http://127.0.0.1:8080/orders while unauthenticated. Every hop below is a real redirect.
|
|
|
|
302 http://127.0.0.1:8080/orders
|
|
302 http://127.0.0.1:8080/oauth2/authorization/demo-web
|
|
302 http://localhost:9000/oauth2/authorize?response_type=code&client_id=demo-web&scope=orders.write%20openid%20profile%20orders.read&state=ONw1L2XOM3BG7j5kgeISWex_263H9-sYOJeG5lcrGv8%3D&redirect_uri=http://127.0.0.1:8080/login/oauth2/code/demo-web&nonce=VSauV4DIo1T-zZKYq8as0fEwQjqmhx462L3sCCBnAHk
|
|
302 http://127.0.0.1:8080/login/oauth2/code/demo-web?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=ONw1L2XOM3BG7j5kgeISWex_263H9-sYOJeG5lcrGv8%3D
|
|
200 http://127.0.0.1:8080/login?error
|
|
|
|
The authorization request the client built:
|
|
http://localhost:9000/oauth2/authorize
|
|
response_type=code
|
|
client_id=demo-web
|
|
scope=orders.write%20openid%20profile%20orders.read
|
|
state=ONw1L2XOM3BG7j5kgeISWex_263H9-sYOJeG5lcrGv8%3D
|
|
redirect_uri=http://127.0.0.1:8080/login/oauth2/code/demo-web
|
|
nonce=VSauV4DIo1T-zZKYq8as0fEwQjqmhx462L3sCCBnAHk
|
|
>>> NO code_challenge - a client registered with
|
|
>>> requireProofKey(true) will reject this outright
|
|
|
|
The flow ended at the CLIENT's error page, not the provider's. The provider
|
|
rejected the authorization request and redirected the failure back to the
|
|
registered redirect_uri, so nothing in the client's logs names the provider
|
|
as the cause. The reason is only in the query string above.
|
|
|
|
------------------------------------------------------------------
|
|
== What the client rendered
|
|
------------------------------------------------------------------
|
|
Please sign in
|
|
Login with OAuth 2.0
|
|
Invalid credentials
|
|
http://localhost:9000
|