2.1. 요청 객체

요청 객체는 JSON으로 인코딩된 OAuth 2.0 인가 요청 매개변수를 JWT Claims Set에 담는 JSON Web Token (JWT) [RFC7519]이다.¶

2.2. 요청 객체 URI

요청 객체 URI는 OAuth 2.0 인가 요청을 구성하는 매개변수 집합을 참조하는 절대 URI이다. URI가 참조하는 리소스의 내용은 요청 객체 (섹션 2.1)이다. 단, 해당 URI가 동일한 인가 서버에 의해 클라이언트에 제공된 경우, 그 내용은 인가 서버의 재량에 따른 구현 세부사항이다. 내용이 요청 객체라는 것은 request_uri의 제공자가 소비자와 별개의 엔티티인 경우, 예를 들어 클라이언트가 HTTPS를 통해 접근 가능하게 만든 클라이언트 백엔드 서비스에 저장된 요청 객체를 참조하는 URI를 제공하는 경우의 상호운용성을 보장하기 위한 것이다. 후자의 경우, 즉 인가 서버가 URI의 제공자이자 소비자인 경우, 예를 들어 요청 객체와 교환하여 URI를 제공하는 엔드포인트를 제공하는 경우에는 이러한 상호운용성 문제가 적용되지 않는다.¶

5.1. 요청 객체를 값으로 전달

클라이언트는 인가 요청을 요청 객체로서 request 매개변수 값으로 인가 엔드포인트에 보낸다.¶

다음은 request 매개변수를 사용하는 인가 요청의 예이다 (표시 목적상 값 안에 줄바꿈이 포함됨):¶

  https://server.example.com/authorize?client_id=s6BhdRkqt3&
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g

5.2. 요청 객체를 참조로 전달

request_uri 인가 요청 매개변수는 OAuth 인가 요청을 값이 아니라 참조로 전달할 수 있게 한다. 이 매개변수는 요청 객체 값이 값으로 전달되는 대신 지정된 URI로 식별되는 리소스에서 검색된다는 점을 제외하면 request 매개변수와 동일하게 사용된다.¶

전체 요청 URI는 512 ASCII 문자를 초과하지 않는 것이 좋다 SHOULD NOT. 이 제한에는 두 가지 이유가 있다:¶

1. 이 문서 작성 시점에 시장의 많은 휴대전화는 여전히 큰 페이로드를 수용하지 않는다. 제한은 일반적으로 512 또는 1024 ASCII 문자이다.¶
2. 2G 모바일 연결과 같은 느린 연결에서는 큰 URL이 느린 응답을 유발하므로, 사용자 경험 관점에서 그러한 사용은 권장되지 않는다.¶

request_uri가 참조하는 리소스의 내용은 요청 객체여야 MUST 하며, 해당 URI가 인가 서버에 의해 클라이언트에 제공된 경우가 아니라면 인가 서버가 접근할 수 있어야 MUST 한다. 첫 번째 경우, request_uri는 [RFC7230]의 섹션 2.7.2에 지정된 https URI여야 MUST 한다. 두 번째 경우, 이는 [RFC8141]에 지정된 URN이어야 MUST 한다.¶

다음은 request_uri에 의해 참조될 수 있는 요청 객체 리소스 내용의 예이다 (표시 목적상 값 안에 줄바꿈이 포함됨):¶

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org

  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

6.1. JWE 암호화된 요청 객체

요청 객체가 암호화된 경우, 인가 서버는 JSON Web Encryption [RFC7516] 명세에 따라 JWT를 복호화해야 MUST 한다.¶

그 결과는 서명된 요청 객체이다.¶

복호화에 실패하면, 인가 서버는 인가 요청에 대한 응답으로 클라이언트에 invalid_request_object 오류를 반환해야 MUST 한다.¶

6.2. JWS 서명된 요청 객체

인가 서버는 JWS 서명된 [RFC7515] 요청 객체의 서명을 검증해야 MUST 한다. kid 헤더 매개변수가 있는 경우, 식별된 키는 사용된 키여야 MUST 하며 클라이언트와 연결된 키여야 MUST 한다. 서명은 클라이언트와 연결된 키와 alg 헤더 매개변수에 지정된 알고리즘을 사용하여 검증되어야 MUST 한다. 알고리즘 검증은 [RFC8725]의 섹션 3.1 및 3.2에 지정된 대로 수행되어야 MUST 한다.¶

키가 클라이언트와 연결되어 있지 않거나 서명 검증에 실패하면, 인가 서버는 인가 요청에 대한 응답으로 클라이언트에 invalid_request_object 오류를 반환해야 MUST 한다.¶

6.3. 요청 매개변수 조립 및 검증

인가 서버는 요청 객체 값에서 인가 요청 매개변수 집합을 추출해야 MUST 한다. 인가 서버는 동일한 매개변수가 쿼리 매개변수로 제공되더라도 요청 객체 안의 매개변수만 사용해야 MUST 한다. client_id 요청 매개변수 안의 클라이언트 ID 값과 요청 객체 client_id Claim 안의 값은 동일해야 MUST 한다. 그런 다음 인가 서버는 OAuth 2.0 [RFC6749]에 지정된 대로 요청을 검증한다.¶

클라이언트 ID 확인 또는 요청 검증에 실패하면, 인가 서버는 [RFC6749]의 섹션 5.2 (OAuth 2.0)에 지정된 대로 인가 요청에 대한 응답으로 클라이언트에 오류를 반환해야 MUST 한다.¶

9.1. OAuth 매개변수 등록

요청 객체는 JWT이므로, 핵심 JWT Claim은 JWT가 지시하는 목적 외에는 요청 객체에서 어떤 목적으로도 사용될 수 없다. 따라서 향후 OAuth 확장이 이들을 다른 의미로 사용하는 것을 피하기 위해 OAuth 인가 요청 매개변수로 등록되었다.¶

이 명세는 [RFC6749]에 의해 설정된 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가한다.¶

이름:

iss¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.1.¶

이름:

sub¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.2.¶

이름:

aud¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.3.¶

이름:

exp¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.4.¶

이름:

nbf¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.5.¶

이름:

iat¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.6.¶

이름:

jti¶

매개변수 사용 위치:

인가 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 [RFC7519]의 섹션 4.1.7.¶

9.2. OAuth 인가 서버 메타데이터 레지스트리

이 명세는 [RFC8414]에 의해 설정된 "OAuth Authorization Server Metadata" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가한다.¶

메타데이터 이름:

require_signed_request_object¶

메타데이터 설명:

인가 요청이 요청 객체로 보호되어야 하며 request 또는 request_uri parameter를 통해 제공되어야 하는 위치를 나타낸다.¶

변경 관리자:

IETF¶

명세 문서:

이 문서의 섹션 10.5.¶

9.3. OAuth 동적 클라이언트 등록 메타데이터 레지스트리

이 명세는 [RFC7591]에 의해 설정된 "OAuth Dynamic Client Registration Metadata" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가한다.¶

메타데이터 이름:

require_signed_request_object¶

메타데이터 설명:

인가 요청이 요청 객체로 보호되어야 하며 request 또는 request_uri parameter를 통해 제공되어야 하는 위치를 나타낸다.¶

변경 관리자:

IETF¶

명세 문서:

이 문서의 섹션 10.5.¶

9.4. 미디어 타입 등록

10.1. 알고리즘 선택

request 매개변수를 통해 인가 요청 객체를 전송할 때, 이는 당시 적절하다고 여겨지는 알고리즘을 사용하여 JWS [RFC7515]로 서명되거나, 또는 각각 JWS [RFC7515] 및 JWE [RFC7516]를 사용하여 서명된 다음 암호화되어야 MUST 한다.¶

10.2. 요청 출처 인증

인가 요청의 출처는 항상 검증되어야 MUST 한다. 이를 수행하는 방법은 여러 가지가 있다:¶

(a)

요청 객체의 JWS 서명 검증.¶

(b)

JWE가 대칭 암호화를 사용하는 경우, JWE 암호화를 위한 대칭 키가 올바른 키인지 검증. 그러나 공개 키 암호화가 사용되는 경우, 누구나 공개 키로 암호화할 수 있으므로 암호화에 의해 출처 인증이 활성화되지는 않는다는 점에 유의한다.¶

(c)

요청 객체 URI의 TLS 서버 신원 검증. 이 경우, 인가 서버는 클라이언트가 요청 객체 URI를 사용하며 해당 TLS 인증서가 클라이언트만을 포함한다는 것을 대역 외로 알고 있어야 MUST 한다. 일반적으로 이는 신뢰할 수 있는 방법이 아니다.¶

(d)

인가 서버가 요청 객체와 교환하여 요청 객체 URI를 반환하는 서비스를 구현하는 경우, 인가 서버는 요청 객체를 수락하기 위해 클라이언트 인증을 수행하고, 자신이 제공하는 요청 객체 URI에 클라이언트 식별자를 바인딩해야 MUST 한다. 또한 (a)에 따라 서명을 검증해야 MUST 한다. 요청 객체 URI는 재사용될 수 있으므로, 요청 객체 URI의 수명은 짧아야 MUST 하며 가능하면 일회용이어야 한다. 요청 객체 URI의 엔트로피는 충분히 커야 MUST 한다. 유효성의 적절한 짧음과 요청 객체 URI의 엔트로피는 보호되는 리소스의 가치를 기반으로 한 위험 계산에 따라 달라진다. 유효 시간에 대한 일반적인 지침은 1분 미만이며, 요청 객체 URI는 이 명세 작성 시점에 128비트 이상의 암호학적 난수 값을 포함하는 것이다.¶

(e)

신뢰할 수 있는 제3자 서비스가 요청 객체와 교환하여 요청 객체 URI를 반환하는 경우, 해당 서비스는 (a)에 따라 서명을 검증해야 MUST 한다. 또한 인가 서버는 그 제3자 서비스에 의해 신뢰되어야 MUST 하며, 클라이언트도 그 서비스에 의해 신뢰된다는 것을 대역 외로 알고 있어야 MUST 한다.¶

10.3. 명시적 엔드포인트

이 명세가 이를 요구하지는 않지만, [BASIN]과 같은 연구는 의도된 상호작용 엔드포인트와 시퀀스 내 메시지 위치를 변조가 드러나는 방식으로 명시하여 개시자의 의도가 모호하지 않도록 하는 것이 좋은 관행임을 지적한다. 이 명세는 [RFC6749], [RFC6750] 및 [RFC8414]에 정의된 다음 엔드포인트에 대해 이 관행을 사용할 것을 RECOMMENDED한다:¶

(a)

보호된 리소스(protected_resources)¶

(b)

인가 엔드포인트(authorization_endpoint)¶

(c)

리디렉션 URI(redirect_uri)¶

(d)

토큰 엔드포인트(token_endpoint)¶

또한 동적 탐색이 사용되는 경우, 이 관행은 탐색 관련 엔드포인트에도 적용된다.¶

[RFC6749]에서는 리디렉션 URI가 인가 요청에 포함되지만, 다른 것들은 포함되지 않는다. 그 결과, 인가 요청 객체에도 동일하게 적용된다.¶

10.4. request_uri와 관련된 위험

request_uri의 도입은 여러 공격 가능성을 도입한다. URI와 관련된 위험에 대한 자세한 정보는 [RFC3986]의 섹션 7의 보안 고려사항을 참조한다.¶

10.5. 다운그레이드 공격

클라이언트와 서버가 사용하는 프로토콜이 OAuth JWT-Secured Authorization Request (JAR)를 사용하도록 고정되어 있지 않으면, 공격자가 RFC 6749 요청을 사용하여 이 명세가 제공하는 모든 보호를 우회할 수 있다.¶

이러한 종류의 공격을 방지하기 위해, 이 명세는 require_signed_request_object라는 이름의 새로운 클라이언트 메타데이터 값과 서버 메타데이터 값을 정의하며, 두 값 모두 boolean이다.¶

클라이언트 메타데이터로서 이 값이 true이면, 서버는 이 명세를 따르지 않는 클라이언트의 인가 요청을 거부해야 MUST 한다. 또한 이 서버 메타데이터 값이 true일 때 요청 객체가 none의 alg 값을 사용하는 경우에도 요청을 거부해야 MUST 한다. 생략된 경우 기본값은 false이다.¶

서버 메타데이터로서 이 값이 true이면, 서버는 이 명세를 따르지 않는 모든 클라이언트의 인가 요청을 거부해야 MUST 한다. 또한 요청 객체가 none의 alg 값을 사용하는 경우에도 요청을 거부해야 MUST 한다. 생략된 경우, 기본값은 false이다.¶

require_signed_request_object 메타데이터 값이 없더라도, 클라이언트와 서버가 상호 지원하는 서명 알고리즘이 있다면 클라이언트는 서명된 요청 객체를 사용할 수 MAY 있다는 점에 유의한다. 서명 알고리즘 메타데이터의 사용은 섹션 4에 설명되어 있다.¶

10.6. TLS 보안 고려사항

현재의 보안 고려사항은 "Transport Layer Security (TLS) 및 Datagram Transport Layer Security (DTLS)의 안전한 사용을 위한 권고" [RFC7525]에서 확인할 수 있다. 이는 OAuth 2.0 [RFC6749]의 TLS 버전 권고를 대체한다.¶

10.7. 매개변수 불일치

OAuth 매개변수 값이 일반 OAuth 매개변수와 요청 객체 Claim이라는 두 위치에서 전송된다는 점을 고려할 때, 구현은 불일치하는 매개변수 값을 사용하여 의도하지 않은 결과를 얻을 수 있는 공격을 방지해야 한다. 이것이 두 클라이언트 ID 값이 일치해야 MUST 하는 이유, 요청 객체의 매개변수 값만 사용해야 하는 이유, 그리고 request도 request_uri도 요청 객체에 나타날 수 없는 이유이다.¶

10.8. 교차 JWT 혼동

[RFC8725]의 섹션 2.8에 설명된 것처럼, 공격자는 한 목적을 위해 발급된 JWT를 의도되지 않은 컨텍스트에서 사용하려고 시도할 수 있다. 이러한 공격에 대해 설명된 완화책은 요청 객체에도 적용할 수 있다.¶

공격자가 요청 객체를 다른 용도로 사용하려고 시도할 수 있는 한 가지 방법은 [RFC7523]의 섹션 2.2에 설명된 것처럼 이를 클라이언트 인증 JWT로 사용하려는 것이다. 이를 방지하는 간단한 방법은 요청 객체에서 클라이언트 ID를 sub 값으로 절대 사용하지 않는 것이다.¶

교차 JWT 혼동을 방지하는 또 다른 방법은 [RFC8725]의 섹션 3.11에 설명된 명시적 타입 지정 사용이다. oauth-authz-req+jwt 값 (섹션 9.4.1에 등록됨)을 갖는 typ 헤더 매개변수를 포함하여 요청 객체의 타입을 명시할 수 있다. 그러나 기존 인가 서버에서 명시적으로 타입이 지정된 요청 객체를 요구하면 대부분의 기존 배포가 깨진다는 점에 유의한다. 기존 클라이언트는 특히 OpenID Connect [OpenID.Core]에서 타입이 지정되지 않은 요청 객체를 이미 일반적으로 사용하고 있기 때문이다. 그러나 기존 배포와의 호환성이 고려사항이 아닌 새로운 OAuth 배포 프로파일에서는 명시적 타입 지정을 요구하는 것이 좋은 생각일 것이다.¶

마지막으로, 교차 JWT 혼동을 방지하는 또 다른 방법은 요청 객체 서명에 사용되는 키가 다른 목적에 사용되는 키와 식별 가능하게 구별되는 키 관리 체계를 사용하는 것이다. 그러면 공격자가 요청 객체를 다른 컨텍스트에서 재사용하려고 시도할 경우 키 불일치가 발생하여 공격이 좌절된다.¶

11.1. 수집 제한

클라이언트가 개인 데이터를 포함하는 보호된 리소스에 대한 접근 권한을 부여받는 경우, 클라이언트는 개인 데이터 수집을 적용 가능한 법의 범위 안에 있고 지정된 목적에 엄격히 필요한 것으로 제한해야 SHOULD 한다.¶

사용자에게 요청된 개인 데이터가 엄격히 필요한지 알아내는 것은 종종 어렵다. 신뢰할 수 있는 제3자 서비스는 클라이언트 요청을 검토하고, 이를 클라이언트가 제안한 처리와 비교하며, 요청을 인증함으로써 사용자를 도울 수 있다. 인증 후 클라이언트는 인가 요청을 할 때, 요청 객체 URI를 얻기 위해 신뢰할 수 있는 제3자 서비스에 인가 요청을 제출할 수 있다. 이 절차는 두 단계로 이루어진다:¶

(1)

(인증 절차) 신뢰할 수 있는 제3자 서비스는 클라이언트의 비즈니스 절차를 검토하고 필요한 Claim을 결정한다; 이것이 인증 절차이다. 클라이언트가 인증되면, 신뢰할 수 있는 제3자 서비스에 요청 객체를 푸시하여 request_uri를 얻기 위해 인증할 수 있는 클라이언트 자격 증명이 발급된다.¶

(2)

(변환 절차) 클라이언트는 받은 클라이언트 자격 증명을 사용하여 신뢰할 수 있는 제3자 서비스에 요청 객체를 푸시하고 request_uri를 얻는다. 신뢰할 수 있는 제3자 서비스는 또한 요청 객체가 이전 단계에 따라 클라이언트가 받을 자격이 있는 Claim과 일치하는지 검증한다.¶

인가 요청에서 이러한 요청 객체 URI를 수신하면, 인가 서버는 먼저 요청 객체 URI의 authority 부분이 신뢰할 수 있는 제3자 서비스에 대한 합법적인 것인지 검증한다. 그런 다음 인가 서버는 요청 객체 URI에 HTTP GET 요청을 보낸다. 연결 시, 인가 서버는 TLS 인증서에 표현된 서버 신원이 요청 객체 URI에 대해 합법적인지 검증해야 MUST 한다. 그런 다음 인가 서버는 클라이언트를 나타내는 client_id를 포함하는 요청 객체를 얻을 수 있다.¶

동의 화면은 클라이언트를 표시해야 MUST 하며, 요청이 신뢰할 수 있는 제3자 서비스에 의해 수집 제한 원칙 준수에 대해 검토되었음을 표시하는 것이 좋다 SHOULD.¶

11.2. 공개 제한