Support enforcing Pushed Authorization Requests (`require_pushed_authorization_requests: true`)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 18/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- java, spring, spring-boot
- Ambito
- authentication, authorization
Direzione di ricerca
The relevant settings live on AuthorizationServerSettings and ClientSettings, and the PAR handling sits in the authorization endpoint's request authentication converter and validator. Start by reading how the pushed authorization request endpoint is wired in the authorization server configurer and how the authorization code request converter parses request_uri. Done means front-channel requests are rejected when the server-wide setting is on, while discovery metadata advertises require_pushed_authorization_requests and existing PAR behaviour is unchanged.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Expected Behavior
First-party support for require_pushed_authorization_requests: true (see RFC 9126, Section 5) - a new, explicit setting that makes PAR mandatory rather than just enabling its endpoint.
While our current use case would be satisfied with a server-wide setting, a client-specific setting might also be useful.
When a server-wide setting is enabled (e.g., requirePushedAuthorizationRequests on AuthorizationServerSettings), I would expect the authorization server to:
- Reject authorization requests that bypass PAR
- Continue validating referenced pushed requests through existing processing
- Automatically advertise
require_pushed_authorization_requests: truein discovery metadata
When configured for a client only (e.g., requirePushedAuthorizationRequests on ClientSettings), I would expect only PAR authorization requests to be accepted for that client, but no server-wide requirement should be advertised in the discovery metadata.
Of course, enabling PAR without enforcing it (as it is today) should be kept for backward compatibility.
Current Behavior
PAR can be enabled through the Spring Security DSL:
.oauth2AuthorizationServer(authorizationServer -> authorizationServer
.pushedAuthorizationRequestEndpoint(withDefaults())
.oidc(withDefaults()))
While this enables the endpoint, it still accepts front-channel authorization requests.
We haven't found a way to enforce it via AuthorizationServerSettings or ClientSettings. Also, setting require_pushed_authorization_requests manually to true through a discovery metadata customizer doesn't enforce it.
For this reason, we created a custom AuthenticationConverter for the authorization endpoint that delegates parsing to OAuth2AuthorizationCodeRequestAuthenticationConverter and then requires exactly one non-blank request_uri.
We originally looked into a custom AuthenticationValidator for the authorization endpoint, but we realized the validator kicks in too late in processing PAR requests and cannot distinguish between parameters supplied by the client and those retrieved through PAR.
Context
We are building a new Identity Provider based on the Spring Authorization Server (Spring Boot 4.1.1 / Spring Security 7.1.1).
Nice to Have
Enhance Spring Boot OAuth2AuthorizationServerProperties to support the new setting(s). Happy to raise a separate issue in the Boot issue tracker once the direction is clear.
- Lingua principale
- Java
- Stelle
- 9.7k
- Fork
- 6.4k
- Merge medio
- 3h 11m
- PR unite (30g)
- 19
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di spring-projects/spring-security
-
Update spring-ldap to 4.0.7Apertatype: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
spring-projects/spring-security#20057 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Update micrometer to 1.16.9Apertatype: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
spring-projects/spring-security#20056 ·
I maintainer di solito rispondono entro 1 giorno
-
Update spring-ldap to 4.1.3Apertatype: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
spring-projects/spring-security#20055 ·
I maintainer di solito rispondono entro 1 giorno
-
Update micrometer to 1.17.3Apertatype: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
spring-projects/spring-security#20054 ·
I maintainer di solito rispondono entro 1 giorno
-
Update spring-ldap to 4.2.0Apertatype: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
spring-projects/spring-security#20053 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di spring-projects/spring-security
Issue simili
-
jules
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
open-learning-exchange/myplanet#18568 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
quarkiverse/quarkus-ironjacamar#264 · 7 commenti ·
-
[Bug]: Login shows only "Log-in failed" when Commons answers the login request with an API errorAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
commons-app/apps-android-commons#7295 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 85/100
hibernate/hibernate-reactive#4485 ·
I maintainer di solito rispondono entro 1 giorno