1.1. 도입 예제

전통적인 OAuth 2.0에서, 클라이언트는 일반적으로 사용자 에이전트가 다음과 같은 HTTP 요청을 인가 서버의 인가 엔드포인트로 보내도록 지시하여 인가 요청을 시작한다(추가 줄바꿈과 들여쓰기는 표시 목적만을 위한 것임):¶

 GET /authorize?response_type=code
  &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
 Host: as.example.com

이러한 요청은 다음 예제에서 보이듯이 클라이언트가 PAR 엔드포인트로 POST 요청을 보내 인가 서버로 직접 푸시할 수도 있다 (추가 줄바꿈과 공백은 표시 목적만을 위한 것임). 요청이 인가 서버로 직접 이루어지므로 클라이언트는 인증할 수 있다 (예: 표시된 것처럼 JWT 클라이언트 assertion 기반 인증 사용).¶

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 &response_type=code
 &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
 &client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE
  lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL
  mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM
  wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA

인가 서버는 요청 URI로 응답한다:¶

 HTTP/1.1 201 Created
 Cache-Control: no-cache, no-store
 Content-Type: application/json

 {
   "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
   "expires_in": 90
 }

클라이언트는 요청 URI 값을 사용하여, 사용자 에이전트가 다음과 같은 HTTP 요청을 인가 서버의 인가 엔드포인트로 보내도록 지시함으로써 이후의 인가 요청을 생성한다(추가 줄바꿈과 들여쓰기는 표시 목적만을 위한 것임):¶

 GET /authorize?client_id=CLIENT1234
  &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
 Host: as.example.com

1.2. 규약 및 용어

이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 및 "OPTIONAL"은 여기에 보이는 것처럼 모두 대문자로 나타날 때에만, BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.¶

이 명세는 "The OAuth 2.0 Authorization Framework" [RFC6749]에서 정의한 "access token", "authorization server", "authorization endpoint", "authorization request", "token endpoint", 및 "client"라는 용어를 사용한다.¶

2.1. 요청

클라이언트는 인가 요청을 구성하는 매개변수를 PAR 엔드포인트로 직접 전송한다. 전형적인 매개변수 집합에는 아래 예제에 보이는 것처럼 client_id, response_type, redirect_uri, scope, state, code_challenge, 및 code_challenge_method가 포함될 수 있다. 그러나 푸시된 인가 요청은 [RFC6749]에서 정의한 것과 모든 적용 가능한 확장을 포함하여, 인가 엔드포인트에서 사용 가능한 모든 매개변수로 구성될 수 있다. request_uri 인가 요청 매개변수는 예외이며, 제공되어서는 안 된다(MUST NOT).¶

요청에는 또한 해당 클라이언트에 적합한 경우 클라이언트 인증에 필요한 추가 매개변수(예: client_secret 또는 client_assertion 및 client_assertion_type)가 포함된다. 이러한 매개변수는 토큰 엔드포인트에서 사용하도록 정의 및 등록되지만, 클라이언트 인증에만 적용된다. 푸시된 인가 요청에 존재할 때, 이들은 클라이언트 인증에만 의존되며 인가 요청 자체와는 관련이 없다. 클라이언트 인증과 관련되지 않은 토큰 엔드포인트 매개변수는 푸시된 인가 요청에 대해 정의된 의미가 없다. client_id 매개변수는 인가 요청과 토큰 엔드포인트 요청 모두에서 동일한 의미로 정의되며, 필수 인가 요청 매개변수로서 푸시된 인가 요청에서도 마찬가지로 요구된다.¶

클라이언트는 부록 B of [RFC6749]에 설명된 대로 UTF-8 문자 인코딩을 사용하여 x-www-form-urlencoded로 형식화된 매개변수로 HTTP POST 요청의 메시지 본문을 구성한다. 적용 가능한 경우, 클라이언트는 토큰 엔드포인트 요청과 동일한 규칙을 사용하여 요청 헤더 또는 요청 본문에 자신의 인증 자격 증명을 추가한다.¶

이는 다음 예제로 설명된다(메시지 본문의 추가 줄바꿈은 표시 목적만을 위한 것임):¶

 POST /as/par HTTP/1.1
 Host: as.example.com
 Content-Type: application/x-www-form-urlencoded

 response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
 &code_challenge_method=S256&scope=account-information
 &client_assertion_type=
  urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
 &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
  OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
  2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
  TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se
  f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K
  dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W
  yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE
  RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6
  GQ

인가 서버는 요청을 다음과 같이 처리해야 한다(MUST):¶

1. 토큰 엔드포인트에서와 같은 방식으로 클라이언트를 인증한다 (섹션 2.3 of [RFC6749]).¶
2. request_uri 인가 요청 매개변수가 제공되면 요청을 거부한다.¶
3. 푸시된 요청을 인가 엔드포인트로 전송된 인가 요청과 같이 검증한다. 예를 들어 인가 서버는 redirect URI가 클라이언트에 대해 구성된 redirect URI 중 하나와 일치하는지 확인하고, 또한 클라이언트가 접근을 요청하는 scope에 대해 권한이 있는지 확인한다. 이 검증을 통해 인가 서버는 승인되지 않았거나 사기성인 요청을 조기에 거부할 수 있다. 인가 서버는 푸시된 요청을 처리할 때 수행할 수 없는 검증 단계를 생략할 수 있다(MAY). 그러나 그러한 확인은 인가 엔드포인트에서 인가 요청을 처리할 때 수행되어야 한다 (MUST).¶

인가 서버는 인증 자격 증명이 있는 클라이언트가 각 푸시된 인가 요청마다 인가 요청별 redirect URI를 설정하도록 허용할 수 있다(MAY). 섹션 2.4에서 더 자세히 설명하듯이, 이는 [RFC6749]와 달리 이 명세가 실제 인가 요청이 수행되기 전에 인가 서버가 클라이언트를 인증하고 클라이언트 요청을 검증할 수 있는 능력을 제공하기 때문에 가능하다.¶

2.2. 성공 응답

검증이 성공하면, 서버는 요청 URI를 생성하고 201 HTTP 상태 코드와 함께 응답에 제공해야 한다(MUST). 다음 매개변수는 [RFC8259]에서 정의한 application/json 미디어 타입을 사용하여 HTTP 응답의 메시지 본문에 최상위 멤버로 포함된다.¶

request_uri

게시된 인가 요청에 대응하는 요청 URI. 이 URI는 이후 인가 요청에서 해당 요청 데이터에 대한 일회용 참조이다. 인가 프로세스가 인가 요청 데이터를 얻는 방식은 인가 서버의 재량이며, 이 명세의 범위를 벗어난다. 이 URI를 통해 다른 당사자에게 인가 요청 데이터를 제공할 필요는 없다.¶

expires_in

요청 URI의 수명을 초 단위의 양의 정수로 나타내는 JSON 숫자. 요청 URI 수명은 인가 서버의 재량이지만 일반적으로 비교적 짧다(예: 5초에서 600초 사이).¶

request_uri 값의 형식은 인가 서버의 재량이지만, 유효한 값을 예측하거나 추측하는 것이 계산상 불가능하도록 암호학적으로 강한 의사난수 알고리즘을 사용해 생성된 일부를 포함해야 한다(MUST) (구체적인 사항은 섹션 10.10 of [RFC6749] 참조). 인가 서버는 해당 인가 요청 데이터를 참조하는 URI의 무작위 부분으로 <reference-value>를 사용하여 urn:ietf:params:oauth:request_uri:<reference-value> 형식으로 request_uri 값을 구성할 수 있다(MAY).¶

request_uri 값은 인가 요청을 게시한 클라이언트에 바인딩되어야 한다(MUST).¶

다음은 그러한 응답의 예이다:¶

 HTTP/1.1 201 Created
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
  "request_uri":
    "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
  "expires_in": 60
 }

2.3. 오류 응답

인가 서버는 섹션 5.2 of [RFC6749]에서 토큰 엔드포인트의 오류 응답에 대해 지정한 것과 동일한 형식으로 오류 응답을 반환하며, 그 안의 적절한 오류 코드 또는 섹션 4.1.2.1 of [RFC6749]의 오류 코드를 사용한다. 섹션 4.1.2.1 of [RFC6749]이 요청 클라이언트로 오류를 자동 리디렉션하는 것을 금지하여 오류 코드를 정의하지 않는 경우(예: 요청이 누락, 유효하지 않음, 또는 불일치하는 리디렉션 URI 때문에 실패한 경우)에는 invalid_request 오류 코드를 기본 오류 코드로 사용할 수 있다. OAuth 확장이 푸시된 인가 요청의 초기 처리에 관련된 경우, 해당 확장에서 정의한 오류 코드도 사용할 수 있다. 푸시된 인가 요청의 초기 처리는 리소스 소유자 상호작용을 포함하지 않으므로, [OIDC]에서 정의한 consent_required와 같은 사용자 상호작용 관련 오류 코드는 절대 반환되지 않는다.¶

인가 서버 또는 클라이언트 정책([RFC9101], 섹션 10.5 참조)에 의해 클라이언트가 서명된 Request Object를 사용해야 하는 경우, 인가 서버는 섹션 3에 제시된 정의를 준수하는 요청만 수락해야 하며(MUST), 그 외의 모든 요청은 HTTP 상태 코드 400 및 오류 코드 invalid_request로 거부해야 한다(MUST).¶

위의 내용에 더하여, PAR 엔드포인트는 다음 HTTP 상태 코드도 사용할 수 있다:¶

405:

요청이 POST 메서드를 사용하지 않은 경우, 인가 서버는 HTTP 405 (Method Not Allowed) 상태 코드로 응답한다.¶

413:

요청 크기가 인가 서버가 허용하는 상한을 초과한 경우, 인가 서버는 HTTP 413 (Payload Too Large) 상태 코드로 응답한다.¶

429:

특정 기간 동안 클라이언트의 요청 수가 인가 서버가 허용하는 수를 초과한 경우, 인가 서버는 HTTP 429 (Too Many Requests) 상태 코드로 응답한다.¶

다음은 PAR 엔드포인트의 오류 응답 예이다:¶

 HTTP/1.1 400 Bad Request
 Content-Type: application/json
 Cache-Control: no-cache, no-store

 {
   "error": "invalid_request",
   "error_description":
     "The redirect_uri is not valid for the given client"
 }

2.4. 클라이언트 리디렉션 URI의 관리

OAuth 2.0 [RFC6749]은 특정 상황에서 클라이언트가 등록되지 않은 redirect_uri 값을 사용하거나, 인가 서버가 인가 엔드포인트에서 클라이언트가 제시한 redirect_uri 값에 자체 매칭 의미론을 적용할 수 있게 한다. 그러나 OAuth security BCP [OAUTH-SECURITY-TOPICS]와 OAuth 2.1 명세 [OAUTH-V2]는 인가 서버가 redirect_uri 매개변수를 특정 클라이언트에 대해 이전에 설정된 redirect URI 집합과 정확히 일치시킬 것을 요구한다. 이는 클라이언트 사칭 시도의 조기 탐지 수단이며, 토큰 유출과 오픈 리디렉션을 방지한다. 단점으로는 redirect URI가 일반적으로 클라이언트 정책에서 가장 변동성이 큰 부분이므로 클라이언트 관리를 더 번거롭게 만들 수 있다.¶

인가 서버와 인증 자격 증명을 설정한 클라이언트에 대해 PAR를 사용할 때는 정확한 매칭 요구사항을 완화할 수 있다(MAY). 이는 전통적인 인가 요청과 달리, 인가 프로세스가 시작되기 전에 인가 서버가 클라이언트를 인증하여 합법적인 클라이언트와 상호작용하고 있음을 보장하기 때문에 가능하다. 인가 서버는 그러한 클라이언트가 인가 서버에 이전에 등록되지 않은 redirect_uri 값을 지정하도록 허용할 수 있다(MAY). 이는 클라이언트에 더 많은 유연성(예: 런타임에 인가 서버별로 서로 다른 redirect_uri 값을 생성)을 제공하고 클라이언트 관리를 단순화할 수 있다. 제공된 redirect_uri 값에 제한을 적용할지는 인가 서버의 재량이다. 예를 들어, 인가 서버는 특정 URI 접두사를 요구하거나 런타임에 쿼리 매개변수만 달라지는 것을 허용할 수 있다(MAY).¶

7.1. 요청 URI 추측

공격자는 유효한 요청 URI 값을 추측하여 재생하고 해당 클라이언트를 사칭하려고 시도할 수 있다. 인가 서버는 JAR [RFC9101], 섹션 10.2의 요청 URI 엔트로피에 관한 조항 (d)에 제시된 고려사항을 반영해야 한다(MUST).¶

7.2. 오픈 리디렉션

공격자는 인가 코드를 얻거나 사용자를 향한 다른 공격을 시작하기 위해 자신이 제어하는 사이트를 가리키는 redirect URI를 등록하려고 시도할 수 있다. 인가 서버는 인증된 클라이언트로부터 푸시된 인가 요청에 있는 새로운 redirect URI만 수락해야 한다(MUST).¶

7.3. Request Object 재생

공격자는 합법적인 인가 요청에서 캡처한 요청 URI를 재생할 수 있다. 이러한 공격에 대처하기 위해, 인가 서버는 요청 URI를 일회용으로 만드는 것이 좋다 (SHOULD).¶

7.4. 클라이언트 정책 변경

Request Object의 등록과 특정 Request Object를 사용하는 인가 요청 사이에 클라이언트 정책이 변경될 수 있다. 따라서 인가 요청을 처리할 때 인가 서버가 요청 매개변수를 클라이언트 정책과 대조하여 확인하는 것이 권장된다.¶

7.5. 요청 URI 바꾸기

공격자는 한 요청에서 요청 URI를 캡처한 다음 이를 다른 인가 요청에 대체할 수 있다. 예를 들어 OpenID Connect 컨텍스트에서, 공격자는 높은 수준의 인증 보증을 요구하는 요청 URI를 더 낮은 수준의 보증을 요구하는 것으로 교체할 수 있다. 클라이언트는 이 공격을 방지하기 위해 푸시된 Request Object에서 PKCE [RFC7636], 고유한 state 매개변수 [RFC6749], 또는 OIDC "nonce" 매개변수 [OIDC]를 사용하는 것이 좋다(SHOULD).¶

9.1. OAuth 인가 서버 메타데이터

IANA는 [RFC8414]에 의해 설정된 [IANA.OAuth.Parameters]의 IANA "OAuth Authorization Server Metadata" 레지스트리에 다음 값을 등록했다.¶

메타데이터 이름:

pushed_authorization_request_endpoint¶

메타데이터 설명:

인가 서버의 푸시된 인가 요청 엔드포인트의 URL.¶

변경 관리 주체:

IESG¶

명세 문서:

RFC 9126의 섹션 5¶

메타데이터 이름:

require_pushed_authorization_requests¶

메타데이터 설명:

인가 서버가 인가 요청을 PAR를 통해서만 수락하는지 여부를 나타낸다.¶

변경 관리 주체:

IESG¶

명세 문서:

RFC 9126의 섹션 5¶

9.2. OAuth 동적 클라이언트 등록 메타데이터

IANA는 [RFC7591]에 의해 설정된 [IANA.OAuth.Parameters]의 IANA "OAuth Dynamic Client Registration Metadata" 레지스트리에 다음 값을 등록했다.¶

클라이언트 메타데이터 이름:

require_pushed_authorization_requests¶

클라이언트 메타데이터 설명:

클라이언트가 인가 요청을 시작하기 위해 PAR를 사용해야 하는지 여부를 나타낸다.¶

변경 관리 주체:

IESG¶

명세 문서:

RFC 9126의 섹션 6¶

9.3. OAuth URI 등록

IANA는 [RFC6755]에 의해 설정된 [IANA.OAuth.Parameters]의 "OAuth URI" 레지스트리에 다음 값을 등록했다.¶

URN:

urn:ietf:params:oauth:request_uri:¶

일반 이름:

OAuth 요청 URI를 위한 URN 하위 네임스페이스.¶

변경 관리 주체:

IESG¶

명세 문서:

RFC 9126의 섹션 2.2¶