Support enforcing Pushed Authorization Requests (`require_pushed_authorization_requests: true`)

オープン
  • 何か問題がありますか？
#20,031 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
18/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java, spring, spring-boot
領域
authentication, authorization

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

status: waiting-for-triage type: enhancement

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: true in 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.

主要言語
Java
スター
9.7k
フォーク
6.4k
平均マージ
3時間 11分
マージ済み PR（30日）
19

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

spring-projects/spring-security のほかの issue

spring-projects/spring-security の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。