인터넷 엔지니어링 태스크 포스 (IETF) J. Richer, Ed.
RFC 요청: 7591
분류: 표준 트랙 M. Jones
ISSN: 2070-1721 Microsoft
J. Bradley
Ping Identity
M. Machulak
Newcastle University
P. Hunt
Oracle Corporation
2015년 7월
OAuth 2.0 동적 클라이언트 등록 프로토콜
초록
이 명세는 인가 서버에 OAuth 2.0 클라이언트를 동적으로
등록하기 위한 메커니즘을 정의한다. 등록 요청은 원하는
클라이언트 메타데이터 값들의 집합을 인가 서버로 보낸다.
그 결과로 반환되는 등록 응답은 인가 서버에서 사용할
클라이언트 식별자와 클라이언트에 대해 등록된 클라이언트
메타데이터 값들을 반환한다. 그런 다음 클라이언트는 이
등록 정보를 사용하여 OAuth 2.0 프로토콜로 인가 서버와
통신할 수 있다. 이 명세는 또한 클라이언트가 등록 중에
사용할 공통 클라이언트 메타데이터 필드 및 값들의 집합도
정의한다.
이 메모의 상태
이는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를
받았으며 인터넷 엔지니어링 운영 그룹(IESG)에 의해
게시가 승인되었다. 인터넷 표준에 대한 추가 정보는
RFC 5741의 섹션 2에서 확인할 수 있다.
이 문서의 현재 상태, 정오표 및 이에 대한 피드백 제공
방법에 관한 정보는
http://www.rfc-editor.org/info/rfc7591에서 얻을 수 있다.
Richer 등 표준 트랙 [1페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Richer 등 표준 트랙 [2페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 표기 규칙 . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. 용어 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. 프로토콜 흐름 . . . . . . . . . . . . . . . . . . . . . 7
2. 클라이언트 메타데이터 . . . . . . . . . . . . . . . . . . . 8
2.1. 권한 부여 유형과 응답 유형 간의 관계 . . . . . . . . . 12
2.2. 사람이 읽을 수 있는 클라이언트 메타데이터 . . . . . . . 13
2.3. 소프트웨어 명세서 . . . . . . . . . . . . . . . . . . . 14
3. 클라이언트 등록 엔드포인트 . . . . . . . . . . . . . . . . 15
3.1. 클라이언트 등록 요청 . . . . . . . . . . . . . . . . . . 16
3.1.1. 소프트웨어 명세서를 사용하는 클라이언트 등록
요청 . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. 응답 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. 클라이언트 정보 응답 . . . . . . . . . . . . . . . . 19
3.2.2. 클라이언트 등록 오류 응답 . . . . . . . . . . . . . 21
4. IANA 고려사항 . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. OAuth 동적 클라이언트 등록 메타데이터 레지스트리 . . . . 22
4.1.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . . 24
4.1.2. 초기 레지스트리 내용 . . . . . . . . . . . . . . . 24
4.2. OAuth 토큰 엔드포인트 인증 방법 레지스트리 . . . . . . 27
4.2.1. 등록 템플릿 . . . . . . . . . . . . . . . . . . . . 28
4.2.2. 초기 레지스트리 내용 . . . . . . . . . . . . . . . 28
5. 보안 고려사항 . . . . . . . . . . . . . . . . . . . . . . . 28
6. 프라이버시 고려사항 . . . . . . . . . . . . . . . . . . . 32
7. 참고 문헌 . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. 규범적 참고 문헌 . . . . . . . . . . . . . . . . . . . 33
7.2. 정보성 참고 문헌 . . . . . . . . . . . . . . . . . . . 35
부록 A. 사용 사례 . . . . . . . . . . . . . . . . . . . . . . 33
A.1. 공개 동적 클라이언트 등록과 보호된 동적 클라이언트 등록 34
A.1.1. 공개 동적 클라이언트 등록 . . . . . . . . . . . . 34
A.1.2. 보호된 동적 클라이언트 등록 . . . . . . . . . . . 34
A.2. 소프트웨어 명세서 없이 또는 사용한 등록 . . . . . . . 34
A.2.1. 소프트웨어 명세서 없는 등록 . . . . . . . . . . . 34
A.2.2. 소프트웨어 명세서를 사용한 등록 . . . . . . . . . 34
A.3. 클라이언트 또는 개발자에 의한 등록 . . . . . . . . . . 34
A.3.1. 클라이언트에 의한 등록 . . . . . . . . . . . . . 35
A.3.2. 개발자에 의한 등록 . . . . . . . . . . . . . . . 35
A.4. 클라이언트 인스턴스별 또는 클라이언트 소프트웨어별 ID 35
A.4.1. 클라이언트 소프트웨어 인스턴스별 클라이언트 ID . . 35
A.4.2. 클라이언트 소프트웨어의 모든 인스턴스 간에
공유되는 클라이언트 ID . . . . . . . . . . . . . . 35
A.5. 상태 저장 또는 무상태 등록 . . . . . . . . . . . . . 35
A.5.1. 상태 저장 클라이언트 등록 . . . . . . . . . . . . 36
A.5.2. 무상태 클라이언트 등록 . . . . . . . . . . . . . . 36
감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Richer 등 표준 트랙 [3페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
1. 소개
OAuth 2.0 [RFC6749] 클라이언트가 OAuth 2.0 인가 서버를
이용하려면, 해당 서버에서 사용할 OAuth 2.0 클라이언트
식별자를 포함하여 서버와 상호작용하는 데 필요한 특정
정보가 필요하다. 이 명세는 OAuth 2.0 클라이언트가 이
정보를 얻기 위해 인가 서버에 동적으로 등록되는 방법을
설명한다.
등록 프로세스의 일부로, 이 명세는 클라이언트가 유효한
리다이렉션 URI 집합과 같은 메타데이터 집합을 인가 서버에
제시할 수 있는 메커니즘도 정의한다. 이 메타데이터는
자체 주장 방식으로 전달되거나, 디지털 서명되었거나
메시지 인증 코드(MAC)로 보호된 소프트웨어 명세서라는
메타데이터 집합으로 전달될 수 있다. 소프트웨어 명세서의
경우, 발급자는 클라이언트에 관한 데이터의 유효성을
보증한다.
전통적으로 클라이언트를 인가 서버에 등록하는 작업은
수동으로 수행된다. 이 명세에서 정의하는 메커니즘은
클라이언트가 인가 서버에 자신을 동적으로 등록하는 데에도,
클라이언트 개발자가 인가 서버에 클라이언트를 프로그래밍
방식으로 등록하는 데에도 사용할 수 있다. OAuth 2.0을
사용하는 여러 애플리케이션은 이전에 이러한 등록을 수행하기
위한 메커니즘을 개발했다. 이 명세는 "OpenID Connect
Dynamic Client Registration 1.0" [OpenID.Registration]에서 정의되고
"User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core]에서
사용되는 등록 메커니즘을 일반화하여, 양쪽 모두와 호환되면서
더 넓은 OAuth 2.0 사용 사례 집합에 적용될 수 있게 한다.
1.1. 표기 규칙
이 문서에서 핵심 단어 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
'OPTIONAL'은 [RFC2119]에 설명된 대로 해석한다.
달리 명시하지 않는 한, 모든 프로토콜 파라미터 이름과 값은
대소문자를 구분한다.
1.2. 용어
이 명세는 OAuth 2.0 [RFC6749]에서 정의한 "access token",
"authorization code", "authorization endpoint", "authorization grant",
"authorization server", "client", "client identifier", "client
secret", "grant type", "protected resource", "redirection URI",
Richer 등 표준 트랙 [4페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
"refresh token", "resource owner", "resource server", "response
type", "token endpoint" 용어와, JSON Web Token (JWT) [RFC7519]에서
정의한 "Claim" 용어를 사용한다.
이 명세는 다음 용어를 정의한다.
클라이언트 소프트웨어
OAuth 2.0 클라이언트를 구현하는 소프트웨어.
클라이언트 인스턴스
클라이언트 소프트웨어 조각의 배포된 인스턴스.
클라이언트 개발자
클라이언트 소프트웨어 패키지를 만들고 배포를 준비하는
사람 또는 조직. 클라이언트가 만들어질 때, 개발자는
배포하는 서비스 제공자 조직이 누구인지 알지 못하는 경우가
많다. 클라이언트 개발자는 배포 URL과 같은 소프트웨어의
측면을 컴파일 시점에 예측할 수 없을 때 동적 등록을
사용해야 한다. 예를 들어, 소프트웨어 API 게시자와 배포
조직이 동일하지 않을 때 이런 일이 발생할 수 있다.
클라이언트 등록 엔드포인트
인가 서버에서 클라이언트를 등록할 수 있는 OAuth 2.0
엔드포인트. 이 엔드포인트의 URL을 얻는 수단은 이 명세의
범위를 벗어난다.
초기 액세스 토큰
인가 서버가 개발자 또는 클라이언트에게 선택적으로 발급하고
클라이언트 등록 엔드포인트 호출을 인가하는 데 사용하는
OAuth 2.0 액세스 토큰. 이 토큰의 유형과 형식은 서비스
고유일 가능성이 높으며 이 명세의 범위를 벗어난다. 인가
서버가 이 토큰을 발급하는 수단과 등록 엔드포인트가 이
토큰을 검증하는 수단도 이 명세의 범위를 벗어난다. 인가
서버가 클라이언트를 등록할 수 있는 당사자를 제한하는 경우,
초기 액세스 토큰의 사용이 필요하다.
배포 조직
소프트웨어 API(서비스)가 배포되고 OAuth 2.0 프레임워크로
보호되는 관리 보안 도메인. 일부 OAuth 시나리오에서는
배포 조직과 소프트웨어 API 게시자가 동일하다. 이러한
경우 배포 조직은 종종 클라이언트 소프트웨어 개발자와
긴밀한 관계를 가진다. 다른 많은 경우에는 서비스의
정의자가 독립적인 제3자 게시자 또는 표준화 조직일 수
있다. API에 대해 게시된 명세를 기준으로 작업할 때,
Richer 등 표준 트랙 [5페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
클라이언트 소프트웨어 개발자는 소프트웨어 API(서비스)를
배포할 잠재적으로 많은 배포 조직과 사전 관계를 맺을 수
없다.
소프트웨어 API 배포
특정 배포 조직 도메인에서 OAuth 2.0(보호된 리소스)으로
보호되는 소프트웨어 API의 배포된 인스턴스. 특정 소프트웨어
API에는 하나 이상의 배포가 있을 수 있다. 소프트웨어 API
배포에는 일반적으로 연결된 OAuth 2.0 인가 서버와
클라이언트 등록 엔드포인트가 있다. 엔드포인트를 얻는
수단은 이 명세의 범위를 벗어난다.
소프트웨어 API 게시자
하나 이상의 배포 환경에 배포될 수 있는 특정 웹 접근 가능
API를 정의하는 조직. 게시자는 OAuth 2.0을 통해 보호될
수 있는 소프트웨어 및 API 명세를 게시하고 배포할 책임이
있는 표준화 기구, 상업 조직, 공공 조직, 민간 조직 또는
오픈 소스 조직이 될 수 있다. 어떤 경우에는 소프트웨어
API 게시자와 클라이언트 개발자가 동일한 조직일 수 있다.
웹 접근 가능 API가 게시되는 시점에, 소프트웨어 게시자는
배포하는 조직들과 사전 관계가 없는 경우가 많다.
소프트웨어 명세서
클라이언트 소프트웨어에 관한 메타데이터 값을 주장하는
디지털 서명되었거나 MAC이 적용된 JSON Web Token (JWT)
[RFC7519]. 어떤 경우에는 소프트웨어 명세서가 클라이언트
개발자에 의해 직접 발급된다. 다른 경우에는 소프트웨어
명세서가 클라이언트 개발자가 사용할 수 있도록 제3자
조직에 의해 발급된다. 두 경우 모두, 인가 서버가
소프트웨어 명세서 발급자와 갖는 신뢰 관계는 등록 요청을
수락할지 평가할 때 입력으로 사용되도록 의도된다. 소프트웨어
명세서는 클라이언트 등록 요청의 일부로 인가 서버에 제시될
수 있다.
Richer 등 표준 트랙 [6페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
1.3. 프로토콜 흐름
+--------(A)- 초기 액세스 토큰 (선택 사항)
|
| +----(B)- 소프트웨어 명세서 (선택 사항)
| |
v v
+-----------+ +---------------+
| |--(C)- 클라이언트 등록 요청 --------->| 클라이언트 |
|클라이언트 | | 등록 |
|또는 개발자|<-(D)- 클라이언트 정보 응답 ----------| 엔드포인트 |
| | 또는 클라이언트 오류 응답 +---------------+
+-----------+
그림 1: 추상 동적 클라이언트 등록 흐름
그림 1에 예시된 추상 OAuth 2.0 클라이언트 동적 등록 흐름은
클라이언트 또는 개발자와 이 명세에서 정의한 엔드포인트 간의
상호작용을 설명한다. 이 그림은 오류 조건을 보여주지 않는다.
이 흐름에는 다음 단계가 포함된다.
(A) 선택적으로, 클라이언트 또는 개발자는 클라이언트 등록
엔드포인트에 대한 접근 권한을 부여하는 초기 액세스
토큰을 발급받는다. 초기 액세스 토큰이 클라이언트 또는
개발자에게 발급되는 방법은 이 명세의 범위를 벗어난다.
(B) 선택적으로, 클라이언트 또는 개발자는 클라이언트 등록
엔드포인트와 함께 사용할 소프트웨어 명세서를 발급받는다.
소프트웨어 명세서가 클라이언트 또는 개발자에게 발급되는
방법은 이 명세의 범위를 벗어난다.
(C) 클라이언트 또는 개발자는 클라이언트가 원하는 등록
메타데이터로 클라이언트 등록 엔드포인트를 호출하며,
인가 서버가 요구하는 경우 선택적으로 (A)의 초기 액세스
토큰을 포함한다.
(D) 인가 서버는 클라이언트를 등록하고 다음을 반환한다.
* 클라이언트의 등록된 메타데이터,
* 서버에서 고유한 클라이언트 식별자, 그리고
* 이 클라이언트에 적용 가능한 경우 클라이언트 시크릿과
같은 클라이언트 자격 증명 집합.
서로 다른 구성 및 사용 예는 부록 A에 포함되어 있다.
Richer 등 표준 트랙 [7페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
2. 클라이언트 메타데이터
등록된 클라이언트는 유효한 리다이렉션 URI 목록이나 표시 이름과
같이, 인가 서버에서 자신의 클라이언트 식별자와 연결된
메타데이터 값 집합을 가진다.
이러한 클라이언트 메타데이터 값은 두 가지 방식으로 사용된다.
o 등록 요청에 대한 입력 값으로, 그리고
o 등록 응답의 출력 값으로.
다음 클라이언트 메타데이터 필드는 이 명세에서 정의한다.
달리 명시하지 않는 한, 모든 클라이언트 메타데이터 필드의
구현과 사용은 선택 사항이다. 모든 데이터 멤버 유형(문자열,
배열, 숫자)은 JSON [RFC7159] 표현을 기준으로 정의된다.
redirect_uris
인가 코드 및 암시적 흐름과 같은 리다이렉션 기반 흐름에서
사용할 리다이렉션 URI 문자열의 배열. OAuth 2.0 [RFC6749]의
섹션 2에서 요구하듯, 리다이렉션을 사용하는 클라이언트는
자신의 리다이렉션 URI 값을 등록해야 한다. 리다이렉션
기반 흐름에 대한 동적 등록을 지원하는 인가 서버는 이
메타데이터 값에 대한 지원을 구현해야 한다.
token_endpoint_auth_method
토큰 엔드포인트에 대해 요청된 인증 방법을 나타내는 문자열
지시자. 이 명세에서 정의하는 값은 다음과 같다.
* "none": 클라이언트는 OAuth 2.0 섹션 2.1에 정의된
공개 클라이언트이며 클라이언트 시크릿을 갖지 않는다.
* "client_secret_post": 클라이언트는 OAuth 2.0
섹션 2.3.1에 정의된 HTTP POST 파라미터를 사용한다.
* "client_secret_basic": 클라이언트는 OAuth 2.0
섹션 2.3.1에 정의된 HTTP Basic을 사용한다.
추가 값은 섹션 4.2에서 설정한 IANA "OAuth Token
Endpoint Authentication Methods" 레지스트리를 통해 정의될
수 있다. 절대 URI도 등록 없이 이 파라미터의 값으로
사용할 수 있다. 지정되지 않거나 생략되면 기본값은
"client_secret_basic"이며, 이는 OAuth 2.0의 섹션 2.3.1에
명시된 HTTP Basic 인증 방식을 나타낸다.
Richer 등 표준 트랙 [8페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
grant_types
클라이언트가 토큰 엔드포인트에서 사용할 수 있는 OAuth 2.0
권한 부여 유형 문자열의 배열. 이러한 권한 부여 유형은
다음과 같이 정의된다.
* "authorization_code": OAuth 2.0 섹션 4.1에 정의된
인가 코드 권한 부여 유형.
* "implicit": OAuth 2.0 섹션 4.2에 정의된 암시적
권한 부여 유형.
* "password": OAuth 2.0 섹션 4.3에 정의된 리소스
소유자 비밀번호 자격 증명 권한 부여 유형.
* "client_credentials": OAuth 2.0 섹션 4.4에 정의된
클라이언트 자격 증명 권한 부여 유형.
* "refresh_token": OAuth 2.0 섹션 6에 정의된 갱신
토큰 권한 부여 유형.
* "urn:ietf:params:oauth:grant-type:jwt-bearer": OAuth JWT
Bearer Token Profiles [RFC7523]에 정의된 JWT Bearer Token
Grant Type.
* "urn:ietf:params:oauth:grant-type:saml2-bearer": OAuth SAML 2
Bearer Token Profiles [RFC7522]에 정의된 SAML 2.0
Bearer Assertion Grant.
권한 부여 유형에서 토큰 엔드포인트가 사용되는 경우, 이
파라미터의 값은 권한 부여 유형 정의에 정의된 토큰
엔드포인트에 전달되는 "grant_type" 파라미터의 값과
동일해야 한다. 인가 서버는 OAuth 2.0 섹션 4.5에 설명된
권한 부여 유형 확장 프로세스에서 정의된 다른 값들을
허용할 수 있다. 생략되면 기본 동작은 클라이언트가
"authorization_code" Grant Type만 사용하는 것이다.
response_types
클라이언트가 인가 엔드포인트에서 사용할 수 있는 OAuth 2.0
응답 유형 문자열의 배열. 이러한 응답 유형은 다음과 같이
정의된다.
* "code": OAuth 2.0 섹션 4.1에 정의된 인가 코드
응답 유형.
* "token": OAuth 2.0 섹션 4.2에 정의된 암시적 응답
유형.
Richer 등 표준 트랙 [9페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
권한 부여 유형에서 인가 엔드포인트가 사용되는 경우, 이
파라미터의 값은 권한 부여 유형 정의에 정의된 인가
엔드포인트에 전달되는 "response_type" 파라미터의 값과
동일해야 한다. 인가 서버는 OAuth 2.0 섹션 4.5에 설명된
권한 부여 유형 확장 프로세스에서 정의된 다른 값들을
허용할 수 있다. 생략되면 기본값은 클라이언트가 "code"
응답 유형만 사용하는 것이다.
client_name
인가 중 최종 사용자에게 제시될, 사람이 읽을 수 있는
클라이언트의 문자열 이름. 생략되면 인가 서버는 대신
원시 "client_id" 값을 최종 사용자에게 표시할 수 있다.
클라이언트가 항상 이 필드를 보내는 것이 권장된다. 이
필드의 값은 섹션 2.2에 설명된 대로 국제화될 수 있다.
client_uri
클라이언트에 관한 정보를 제공하는 웹 페이지의 URL 문자열.
존재하는 경우, 서버는 이 URL을 클릭 가능한 방식으로 최종
사용자에게 표시해야 한다. 클라이언트가 항상 이 필드를
보내는 것이 권장된다. 이 필드의 값은 유효한 웹 페이지를
가리켜야 한다. 이 필드의 값은 섹션 2.2에 설명된 대로
국제화될 수 있다.
logo_uri
클라이언트의 로고를 참조하는 URL 문자열. 존재하는 경우,
서버는 승인 중 이 이미지를 최종 사용자에게 표시해야 한다.
이 필드의 값은 유효한 이미지 파일을 가리켜야 한다. 이
필드의 값은 섹션 2.2에 설명된 대로 국제화될 수 있다.
scope
클라이언트가 액세스 토큰을 요청할 때 사용할 수 있는
범위 값의 공백으로 구분된 목록을 포함하는 문자열(OAuth 2.0
[RFC6749]의 섹션 3.3에 설명됨). 이 목록의 값 의미는
서비스 고유이다. 생략되면, 인가 서버는 기본 범위 집합으로
클라이언트를 등록할 수 있다.
contacts
이 클라이언트에 책임이 있는 사람들에게 연락할 방법을
나타내는 문자열 배열로, 일반적으로 이메일 주소이다. 인가
서버는 클라이언트에 대한 지원 요청을 위해 이러한 연락처
주소를 최종 사용자에게 제공할 수 있다. 프라이버시
고려사항에 관한 정보는 섹션 6을 참조한다.
Richer 등 표준 트랙 [10페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
tos_uri
클라이언트를 위한 사람이 읽을 수 있는 서비스 약관 문서를
가리키는 URL 문자열. 이 문서는 최종 사용자가 클라이언트를
인가할 때 수락하는, 최종 사용자와 클라이언트 간의 계약상
관계를 설명한다. 제공되는 경우 인가 서버는 이 URL을 최종
사용자에게 표시해야 한다. 이 필드의 값은 유효한 웹
페이지를 가리켜야 한다. 이 필드의 값은 섹션 2.2에
설명된 대로 국제화될 수 있다.
policy_uri
배포 조직이 개인 데이터를 수집, 사용, 보관 및 공개하는
방법을 설명하는 사람이 읽을 수 있는 개인정보 처리방침
문서를 가리키는 URL 문자열. 제공되는 경우 인가 서버는
이 URL을 최종 사용자에게 표시해야 한다. 이 필드의 값은
유효한 웹 페이지를 가리켜야 한다. 이 필드의 값은
섹션 2.2에 설명된 대로 국제화될 수 있다.
jwks_uri
클라이언트의 공개 키를 포함하는 클라이언트의 JSON Web Key
(JWK) Set [RFC7517] 문서를 참조하는 URL 문자열. 이 필드의
값은 유효한 JWK Set 문서를 가리켜야 한다. 이러한 키는
서명 또는 암호화를 사용하는 상위 수준 프로토콜에서 사용할
수 있다. 예를 들어, 일부 애플리케이션에서 클라이언트 인증에
JWT를 사용할 때 토큰 엔드포인트로 전송되는 서명된 요청을
검증하는 데 이러한 키가 사용될 수 있다 [RFC7523].
이 파라미터는 키 순환을 더 쉽게 하므로 "jwks" 파라미터보다
사용하는 것이 선호된다. "jwks_uri" 및 "jwks" 파라미터는
동일한 요청 또는 응답에 둘 다 존재해서는 안 된다.
jwks
클라이언트의 공개 키를 포함하는 클라이언트의 JSON Web Key
Set [RFC7517] 문서 값. 이 필드의 값은 유효한 JWK Set을
포함하는 JSON 객체여야 한다. 이러한 키는 서명 또는
암호화를 사용하는 상위 수준 프로토콜에서 사용할 수 있다.
이 파라미터는 공용 URL을 호스트할 수 없는 네이티브
클라이언트처럼 "jwks_uri" 파라미터를 사용할 수 없는
클라이언트가 사용하도록 의도된다. "jwks_uri" 및 "jwks"
파라미터는 동일한 요청 또는 응답에 둘 다 존재해서는 안
된다.
software_id
클라이언트 개발자 또는 소프트웨어 게시자가 할당하고, 등록
엔드포인트가 동적으로 등록될 클라이언트 소프트웨어를
식별하는 데 사용하는 고유 식별자 문자열(예: Universally
Unique Identifier (UUID)). 인가 서버가 발급하고 인스턴스
간에 달라지는 것이 바람직한 "client_id"와 달리,
"software_id"는 클라이언트 소프트웨어의 모든 인스턴스에
대해 동일하게 유지되는 것이 바람직하다. "software_id"는
Richer 등 표준 트랙 [11페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
동일한 소프트웨어 조각의 여러 업데이트나 버전에 걸쳐 동일하게
유지되는 것이 바람직하다. 이 필드의 값은 사람이 읽도록
의도된 것이 아니며 보통 클라이언트와 인가 서버에게
불투명하다.
software_version
"software_id"로 식별되는 클라이언트 소프트웨어의 버전
식별자 문자열. "software_version"의 값은 동일한
"software_id"로 식별되는 클라이언트 소프트웨어가 업데이트될
때마다 변경되는 것이 바람직하다. 이 필드의 값은 문자열
동등성 일치로 비교되도록 의도되며, 이 명세에서는 다른
비교 의미를 정의하지 않는다. 이 필드의 값은 이 명세의
범위를 벗어나지만, 사람이 읽도록 의도된 것이 아니며 보통
클라이언트와 인가 서버에게 불투명하다. 이 값의 변경을
유발하는 클라이언트 소프트웨어 업데이트가 무엇인지에 대한
정의는 소프트웨어 자체에 고유하며 이 명세의 범위를
벗어난다.
이 명세의 확장 및 프로파일은 이 문서의 섹션 4의 IANA
고려사항에 따라 등록된 메타데이터 이름과 설명으로 이 목록을
확장할 수 있다. 인가 서버는 자신이 이해하지 못하는, 클라이언트가
보낸 모든 클라이언트 메타데이터를 무시해야 한다(예를 들어,
처리 중 클라이언트의 등록 레코드에서 알 수 없는 메타데이터를
조용히 제거함). 인가 서버는 요청된 값을 섹션 3.2.1에
설명된 적절한 기본값으로 대체하거나, 섹션 3.2.2에 설명된
오류 응답을 반환하여, 요청된 클라이언트 메타데이터 값을
거부할 수 있다.
클라이언트 메타데이터 값은 섹션 3.1에 설명된 대로 등록
요청 본문에서 직접 전달될 수도 있고, 섹션 2.3에 설명된
대로 소프트웨어 명세서의 클레임으로 포함될 수도 있다. 둘을
혼합하는 것도 가능하다. 동일한 클라이언트 메타데이터 이름이
두 위치 모두에 존재하고 소프트웨어 명세서가 인가 서버에 의해
신뢰되는 경우, 소프트웨어 명세서의 클레임 값이 우선해야 한다.
2.1. 권한 부여 유형과 응답 유형 간의 관계
위에서 설명한 "grant_types" 및 "response_types" 값은 OAuth
프로토콜의 서로 다른 엔드포인트에 전달되는 인수를 가리키므로
부분적으로 직교한다. 그러나 클라이언트가 사용할 수 있는
"grant_types"가 클라이언트가 사용할 수 있는 "response_types"에
영향을 주고 그 반대도 마찬가지라는 점에서 둘은 관련되어
있다. 예를 들어, "authorization_code"를 포함하는
"grant_types" 값은 "code"를 포함하는 "response_types" 값을
암시한다. 두 값 모두 OAuth 2.0 인가 코드 권한 부여의 일부로
정의되기 때문이다. 따라서 이러한 필드를 지원하는 서버는
Richer 등 표준 트랙 [12페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
예를 들어 일관성 없는 등록 요청에 대해
"invalid_client_metadata" 오류 응답을 반환함으로써, 클라이언트가
자신을 일관성 없는 상태로 등록할 수 없도록 조치를 취해야 한다.
두 필드 간의 상관관계는 아래 표에 나열되어 있다.
+-----------------------------------------------+-------------------+
| grant_types 값에 포함되는 항목: | response_types |
| | 값에 포함되는 항목:|
+-----------------------------------------------+-------------------+
| authorization_code | code |
| implicit | token |
| password | (없음) |
| client_credentials | (없음) |
| refresh_token | (없음) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (없음) |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (없음) |
+-----------------------------------------------+-------------------+
"grant_types" 또는 "response_types" 파라미터에 새 값을 도입하는
이 문서의 확장 및 프로파일은 이 두 파라미터 유형 간의 모든
대응 관계를 문서화해야 한다.
2.2. 사람이 읽을 수 있는 클라이언트 메타데이터
사람이 읽을 수 있는 클라이언트 메타데이터 값과 사람이 읽을 수
있는 값을 참조하는 클라이언트 메타데이터 값은 여러 언어와
문자 체계로 표현될 수 있다. 예를 들어, "client_name",
"tos_uri", "policy_uri", "logo_uri", "client_uri"와 같은 필드의
값은 일부 클라이언트 등록에서 다양한 위치에서의 사용을
용이하게 하기 위해 여러 로케일별 값을 가질 수 있다.
언어와 문자 체계를 지정하기 위해, BCP 47 [RFC5646] 언어 태그가
"#" 문자로 구분되어 클라이언트 메타데이터 멤버 이름에 추가된다.
JSON [RFC7159] 멤버 이름은 대소문자를 구분하므로, Claim Names에
사용되는 언어 태그 값은 "IANA Language Subtag" 레지스트리
[IANA.Language]에 등록된 문자 대소문자를 사용해 표기하는 것이
권장된다. 특히 일반적으로 언어 이름은 소문자로, 지역 이름은
대문자로, 언어는 대소문자가 혼합된 형태로 표기된다. 그러나
BCP 47 언어 태그 값은 대소문자를 구분하지 않으므로, 구현은
제공된 언어 태그 값을 대소문자를 구분하지 않는 방식으로
해석해야 한다. BCP 47의 권고에 따라, 메타데이터 멤버
이름에 사용되는 언어 태그 값은 필요한 만큼만 구체적이어야
한다. 예를 들어, 많은 문맥에서는 "fr-CA" 또는 "fr-FR"보다
"fr"을 사용하는 것으로 충분할 수 있다.
Richer 등 표준 트랙 [13페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
예를 들어, 클라이언트는 동일한 등록 요청 내에서 자신의 영어
이름을 "client_name#en": "My Client"로, 일본어 이름을
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"로 표현할 수 있다.
인가 서버는 인가 단계에서 리소스 소유자에게 이러한 이름 중
일부 또는 전부를 표시할 수 있으며, 어떤 이름을 표시할지는
시스템 구성, 사용자 기본 설정 또는 기타 요인을 기준으로
선택한다.
사람이 읽을 수 있는 필드가 언어 태그 없이 전송되는 경우, 이를
사용하는 당사자는 문자열 값의 언어, 문자 집합 또는 문자 체계에
대해 어떠한 가정도 해서는 안 되며, 문자열 값은 사용자
인터페이스에 표시되는 모든 곳에서 그대로 사용되어야 한다.
상호운용성을 용이하게 하기 위해, 클라이언트와 서버는 언어별
필드에 더해 언어 태그가 없는 사람이 읽을 수 있는 필드를
사용하는 것이 권장되며, 언어 태그 없이 전송되는 사람이 읽을 수
있는 필드에는 다양한 시스템에서 표시하기에 적합한 값을
포함하는 것이 권장된다.
구현자 참고: 많은 JSON 라이브러리는 JSON 객체의 멤버를
라이브러리의 네이티브 프로그래밍 환경에서 객체 구성체의
멤버로 참조할 수 있게 한다. 그러나 "#" 문자는 JSON 객체의
멤버 이름 안에서는 유효한 문자이지만, 많은 프로그래밍
환경에서 객체 멤버 이름으로 사용하는 데에는 유효한 문자가
아니다. 따라서 구현은 이러한 클레임에 대해 대체 접근 형식을
사용해야 한다. 예를 들어 JavaScript에서 JSON을 다음과 같이
파싱했다면, "var j = JSON.parse(json);", 해결 방법으로 멤버
"client_name#en-us"는 JavaScript 구문
"j["client_name#en-us"]"를 사용하여 접근할 수 있다.
2.3. 소프트웨어 명세서
소프트웨어 명세서는 클라이언트 소프트웨어에 관한 메타데이터
값을 묶음으로 주장하는 JSON Web Token (JWT) [RFC7519]이다.
소프트웨어 명세서에서 사용할 수 있는 클레임 집합은
섹션 2에 정의되어 있다. 클라이언트 등록 요청의 일부로 인가
서버에 제시될 때, 소프트웨어 명세서는 JSON Web Signature
(JWS) [RFC7515]를 사용해 디지털 서명되거나 MAC이 적용되어야 하며,
소프트웨어 명세서의 클레임을 증명하는 당사자를 나타내는
"iss" (issuer) 클레임을 포함해야 한다. 특정 애플리케이션이
다른 알고리즘의 사용을 지정할 수는 있지만, 소프트웨어 명세서는
"RS256" 서명 알고리즘을 사용해 디지털 서명되는 것이 권장된다.
인가 서버가 동일한 소프트웨어 명세서를 사용하는 서로 다른
소프트웨어 인스턴스를 상관시킬 수 있도록, 소프트웨어 명세서에는
"software_id" 클레임을 포함하는 것이 권장된다.
Richer 등 표준 트랙 [14페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
예를 들어, 소프트웨어 명세서는 다음 클레임을 포함할 수 있다.
{
"software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/"
}
다음 비규범 예시 JWT는 이러한 클레임을 포함하며 "RS256"을
사용해 비대칭 서명되었다(줄바꿈은 표시 목적만을 위한 것이다).
eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
소프트웨어 명세서는 일반적으로 클라이언트 애플리케이션의 모든
인스턴스와 함께 배포된다. 클라이언트 또는 개발자가
소프트웨어 명세서를 얻는 수단은 이 명세의 범위를 벗어난다.
일반적인 방법으로는, 클라이언트 개발자가 소프트웨어 API
게시자에 등록하여 특정 클라이언트 부류에 대한 소프트웨어
명세서를 얻고 클라이언트별 JWT를 생성하는 것이 포함될 수 있다.
인가 서버가 소프트웨어 명세서의 정보를 신뢰하고 활용할지
결정하는 기준은 이 명세의 범위를 벗어난다.
어떤 경우에는, 인가 서버가 사전 동적 클라이언트 등록이
수행되지 않았더라도 인가 요청에서 소프트웨어 명세서 값을
직접 클라이언트 식별자로 수락하도록 선택할 수 있다. 인가
서버가 그렇게 하는 상황과 이 경우 요구되는 특정 소프트웨어
명세서 특성은 이 명세의 범위를 벗어난다.
3. 클라이언트 등록 엔드포인트
클라이언트 등록 엔드포인트는 클라이언트가 인가 서버에 등록될
수 있도록 설계된, 이 문서에서 정의하는 OAuth 2.0
엔드포인트이다. 클라이언트 등록 엔드포인트는 요청 파라미터가
Richer 등 표준 트랙 [15페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
엔터티 본문에 "application/json" 형식으로 인코딩된 HTTP POST
메시지를 수락해야 한다. 클라이언트 등록 엔드포인트는
섹션 5에 설명된 전송 계층 보안 메커니즘으로 보호되어야 한다.
클라이언트 등록 엔드포인트는 OAuth 2.0 [RFC6749] 보호
리소스일 수 있으며, 등록을 이전에 인가된 당사자에게만
제한하기 위해 OAuth 2.0 액세스 토큰 형태의 초기 액세스 토큰을
수락할 수 있다. 클라이언트 또는 개발자가 초기 액세스 토큰을
얻는 방법은 일반적으로 대역 외이며 이 명세의 범위를 벗어난다.
클라이언트 등록 엔드포인트가 초기 액세스 토큰을 확인하고
검증하는 방법도 이 명세의 범위를 벗어난다.
공개 등록을 지원하고 더 넓은 상호운용성을 용이하게 하기 위해,
클라이언트 등록 엔드포인트는 인가 없는 등록 요청(즉, 요청에
초기 액세스 토큰이 없는 요청)을 허용해야 한다. 이러한 요청은
클라이언트 등록 엔드포인트에 대한 서비스 거부 공격을 방지하기
위해 비율 제한되거나 달리 제한될 수 있다.
3.1. 클라이언트 등록 요청
이 동작은 클라이언트를 인가 서버에 등록한다. 인가 서버는 이
클라이언트에 고유한 클라이언트 식별자를 할당하고, 선택적으로
클라이언트 시크릿을 할당하며, 요청에 제공된 메타데이터를
발급된 클라이언트 식별자와 연결한다. 요청에는 등록 중
클라이언트에 대해 지정되는 모든 클라이언트 메타데이터
파라미터가 포함된다. 인가 서버는 클라이언트 메타데이터에서
생략된 항목에 대해 기본값을 프로비저닝할 수 있다.
등록하려면 클라이언트 또는 개발자는 콘텐츠 유형
"application/json"으로 클라이언트 등록 엔드포인트에 HTTP POST를
보낸다. HTTP Entity Payload는 JSON 객체와 그 JSON 객체의
최상위 멤버로 포함된 모든 요청 클라이언트 메타데이터 값으로
구성된 JSON [RFC7159] 문서이다.
예를 들어, 서버가 공개 등록(초기 액세스 토큰 없음)을 지원하는
경우, 클라이언트는 다음 등록 요청을 클라이언트 등록
엔드포인트에 보낼 수 있다.
Richer 등 표준 트랙 [16페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
다음은 초기 액세스 토큰을 사용하지 않는 비규범 예시 요청이다.
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"example_extension_parameter": "example_value"
}
또는, 서버가 인가된 등록을 지원하는 경우, 개발자 또는
클라이언트에는 초기 액세스 토큰이 프로비저닝된다. (초기
액세스 토큰을 얻는 방법은 이 명세의 범위를 벗어난다.)
개발자 또는 클라이언트는 다음 인가된 등록 요청을 클라이언트
등록 엔드포인트에 보낸다. 이 예시에서 초기 액세스 토큰은
OAuth 2.0 Bearer Token [RFC6750]으로 전송되지만, 인가 서버는
어떤 OAuth 2.0 토큰 유형도 사용할 수 있다는 점에 유의한다.
Richer 등 표준 트랙 [17페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
다음은 초기 액세스 토큰을 사용하고 JWK Set을 값으로 등록하는
비규범 예시 요청이다(값 안의 줄바꿈은 표시 목적만을 위한
것이다).
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com
{
"redirect_uris": ["https://client.example.org/callback",
"https://client.example.org/callback2"],
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method": "client_secret_basic",
"policy_uri": "https://client.example.org/policy.html",
"jwks": {"keys": [{
"e": "AQAB",
"n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
"kty": "RSA"
}]},
"example_extension_parameter": "example_value"
}
3.1.1. 소프트웨어 명세서를 사용하는 클라이언트 등록 요청
JSON 요소에 더해, 클라이언트 메타데이터 값은 섹션 2.3에
설명된 대로 소프트웨어 명세서로도 제공될 수 있다. 인가
서버가 이 기능을 지원하지 않는 경우 소프트웨어 명세서를
무시할 수 있다. 서버가 소프트웨어 명세서를 지원하는 경우,
소프트웨어 명세서로 전달된 클라이언트 메타데이터 값은 일반
JSON 요소를 사용해 전달된 값보다 우선해야 한다.
소프트웨어 명세서는 다음 선택적 멤버를 사용해 요청 JSON 객체에
포함된다.
software_statement
클라이언트 소프트웨어에 관한 클라이언트 메타데이터 값을
클레임으로 포함하는 소프트웨어 명세서. 이는 전체 서명된
JWT를 포함하는 문자열 값이다.
Richer 등 표준 트랙 [18페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
다음 예시에서는 일부 등록 파라미터가 섹션 2.3의 예시에서 온
소프트웨어 명세서의 클레임으로 전달되고, 클라이언트 인스턴스에
특정한 일부 값은 일반 파라미터로 전달된다(값 안의 줄바꿈은
표시 목적만을 위한 것이다).
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"
],
"software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
"scope": "read write",
"example_extension_parameter": "example_value"
}
3.2. 응답
등록 요청이 성공하면, 인가 서버는 클라이언트에 대한 클라이언트
식별자를 반환한다. 서버는 HTTP 201 Created 상태 코드와 함께,
섹션 3.2.1에 설명된 내용이 포함된 "application/json" 유형의
본문으로 응답한다.
등록 요청이 실패하면, 인가 서버는 섹션 3.2.2에 설명된 대로
오류로 응답한다.
3.2.1. 클라이언트 정보 응답
응답은 클라이언트 식별자와, 클라이언트가 기밀 클라이언트인
경우 클라이언트 시크릿을 포함한다. 응답은 이 명세의 확장에서
지정한 추가 필드를 포함할 수 있다.
Richer 등 표준 트랙 [19페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
client_id
필수. OAuth 2.0 클라이언트 식별자 문자열. 현재 다른
등록된 클라이언트에 대해 유효해서는 안 되지만, 인가 서버는
재량에 따라 등록된 클라이언트의 여러 인스턴스에 동일한
클라이언트 식별자를 발급할 수 있다.
client_secret
선택 사항. OAuth 2.0 클라이언트 시크릿 문자열. 발급되는
경우, 이는 각 "client_id"에 대해 고유해야 하며, 동일한
"client_id"를 사용하는 클라이언트의 여러 인스턴스에 대해
고유한 것이 바람직하다. 이 값은 OAuth 2.0
[RFC6749], 섹션 2.3.1에 설명된 대로 기밀 클라이언트가
토큰 엔드포인트에 인증하는 데 사용된다.
client_id_issued_at
선택 사항. 클라이언트 식별자가 발급된 시각. 이 시각은
UTC로 측정한 1970-01-01T00:00:00Z부터 발급 일시까지의
초 수로 표현된다.
client_secret_expires_at
"client_secret"이 발급된 경우 필수. 클라이언트 시크릿이
만료되는 시각 또는 만료되지 않는 경우 0. 이 시각은 UTC로
측정한 1970-01-01T00:00:00Z부터 만료 일시까지의 초 수로
표현된다.
또한 인가 서버는 인가 서버 자체가 프로비저닝한 모든 필드를
포함하여, 이 클라이언트에 관한 모든 등록된 메타데이터를
반환해야 한다. 인가 서버는 등록 중 제출된 클라이언트의 요청
메타데이터 값 중 어느 것이든 거부하거나 적절한 값으로 대체할
수 있다. 클라이언트 또는 개발자는 응답의 값을 확인하여
등록이 사용하기에 충분한지(예: 등록된
"token_endpoint_auth_method"가 클라이언트 소프트웨어에서
지원되는지) 판단하고, 클라이언트 소프트웨어에 적절한 조치
방침을 결정할 수 있다. 이러한 상황에 대한 응답은 이 명세의
범위를 벗어나지만, 애플리케이션 개발자 또는 인가 서버
제공자에게 보고서를 제출하거나, 다른 메타데이터 값으로 재등록을
시도하거나, 기타 다양한 방법을 포함할 수 있다. 예를 들어,
서버가 [RFC7592]에 정의된 것과 같은 등록 관리 메커니즘도
지원하는 경우, 클라이언트 또는 개발자는 다른 메타데이터 값으로
등록을 업데이트하려고 시도할 수 있다. 이 과정은
[OpenID.Discovery]와 같은 서비스 발견 프로토콜의 도움을 받을
수도 있다. 이 프로토콜은 서버의 기능을 나열할 수 있어
클라이언트가 더 많은 정보를 바탕으로 등록 요청을 만들 수 있게
한다. 그러한 관리 또는 발견 시스템의 사용은 선택 사항이며
이 명세의 범위를 벗어난다.
Richer 등 표준 트랙 [20페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
성공한 등록 응답은 HTTP 201 Created 상태 코드를 사용하며,
객체의 최상위 멤버로 모든 파라미터를 가진 단일 JSON 객체
[RFC7159]로 구성된 "application/json" 유형의 본문을 포함한다.
등록의 일부로 소프트웨어 명세서가 사용된 경우, 그 값은
"software_statement" 멤버 이름을 사용해 다른 메타데이터와 함께
수정되지 않은 채 응답에 반환되어야 한다. 소프트웨어 명세서에서
사용된 클라이언트 메타데이터 요소도 등록 응답에서 최상위
클라이언트 메타데이터 값으로 직접 반환되어야 한다(요청된 값과
사용된 값이 다를 수 있으므로 다른 값일 수도 있다).
다음은 성공한 등록에 대한 비규범 예시 응답이다.
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at": 2893256800,
"client_secret_expires_at": 2893276800,
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"example_extension_parameter": "example_value"
}
3.2.2. 클라이언트 등록 오류 응답
클라이언트가 유효하지 않은 초기 액세스 토큰을 제시하는 경우와
같이 OAuth 2.0 오류 조건이 발생하면, 인가 서버는 OAuth 2.0
토큰 유형에 적절한 오류 응답을 반환한다.
Richer 등 표준 트랙 [21페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
등록 오류 조건이 발생하면, 인가 서버는 (달리 지정되지 않는 한)
HTTP 400 상태 코드를 반환하며, 응답 본문에 오류를 설명하는
JSON 객체 [RFC7159]로 구성된 콘텐츠 유형 "application/json"을 포함한다.
JSON 객체에 포함하기 위해 두 멤버가 정의된다.
error
필수. 단일 ASCII 오류 코드 문자열.
error_description
선택 사항. 디버깅에 사용되는 사람이 읽을 수 있는 ASCII
텍스트 오류 설명.
다른 멤버도 포함될 수 있으며, 이해되지 않는 경우에는 무시되어야
한다.
이 명세는 다음 오류 코드를 정의한다.
invalid_redirect_uri
하나 이상의 리다이렉션 URI 값이 유효하지 않다.
invalid_client_metadata
클라이언트 메타데이터 필드 중 하나의 값이 유효하지 않으며
서버가 이 요청을 거부했다. 인가 서버는 클라이언트
메타데이터의 요청된 파라미터 중 어느 것에 대해서도 유효한
값으로 대체하도록 선택할 수 있다는 점에 유의한다.
invalid_software_statement
제시된 소프트웨어 명세서가 유효하지 않다.
unapproved_software_statement
제시된 소프트웨어 명세서는 이 인가 서버에서 사용하도록
승인되지 않았다.
Richer 등 표준 트랙 [22페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
다음은 인가 서버가 블랙리스트에 올린 리다이렉션 URI로 인해
발생한 오류 응답의 비규범 예시이다(값 안의 줄바꿈은 표시
목적만을 위한 것이다).
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_redirect_uri",
"error_description": "The redirection URI
http://sketchy.example.com is not allowed by this server."
}
다음은 "response_types"와 "grant_types" 값의 일관성 없는 조합으로
인해 발생한 오류 응답의 비규범 예시이다(값 안의 줄바꿈은 표시
목적만을 위한 것이다).
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_client_metadata",
"error_description": "The grant type 'authorization_code' must be
registered along with the response type 'code' but found only
'implicit' instead."
}
4. IANA 고려사항
4.1. OAuth 동적 클라이언트 등록 메타데이터 레지스트리
이 명세는 "OAuth Dynamic Client Registration Metadata" 레지스트리를
설정한다.
OAuth 등록 클라이언트 메타데이터 이름과 설명은 하나 이상의
지정 전문가의 조언에 따라, oauth-ext-review@ietf.org 메일링
리스트에서 2주 검토 기간을 거친 뒤 Specification Required
([RFC5226])로 등록된다. 그러나 게시 전에 이름을 할당할 수
있도록, 지정 전문가는 [RFC7120]에 따라 해당 명세가 게시될 것이라고
만족하면 등록을 승인할 수 있다.
Richer 등 표준 트랙 [23페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
검토를 위해 메일링 리스트로 전송되는 등록 요청은 적절한 제목
(예: "Request to register OAuth Dynamic Client Registration Metadata
name: example")을 사용해야 한다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고,
이 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명이
포함되어야 하며, 해당되는 경우 요청을 성공하게 만드는 방법에
대한 제안도 포함되어야 한다.
IANA는 지정 전문가로부터 온 레지스트리 업데이트만 수락해야
하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다.
4.1.1. 등록 템플릿
Client Metadata Name:
요청된 이름(예: "example"). 이 이름은 대소문자를 구분한다.
대소문자를 구분하지 않는 방식으로 다른 등록된 이름과
일치하는 이름은 수락하지 않는 것이 바람직하다.
Client Metadata Description:
메타데이터 값에 대한 간단한 설명(예: "Example
description").
Change Controller:
표준 트랙 RFC의 경우 "IESG"를 나열한다. 그 외의 경우에는
책임 당사자의 이름을 제공한다. 기타 세부 정보(예: 우편
주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다.
Specification Document(s):
클라이언트 메타데이터 정의를 지정하는 문서 또는 문서들에
대한 참조이며, 가능한 경우 해당 문서의 사본을 가져오는 데
사용할 수 있는 URI를 포함한다. 관련 섹션의 표시도 포함될
수 있지만 필수는 아니다.
4.1.2. 초기 레지스트리 내용
"OAuth Dynamic Client Registration Metadata" 레지스트리의 초기
내용은 다음과 같다.
o Client Metadata Name: "redirect_uris"
o Client Metadata Description: 리다이렉션 기반 흐름에서 사용할
리다이렉션 URI의 배열
o Change Controller: IESG
o Specification Document(s): RFC 7591
Richer 등 표준 트랙 [24페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
o Client Metadata Name: "token_endpoint_auth_method"
o Client Metadata Description: 토큰 엔드포인트에 대해 요청된 인증
방법
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "grant_types"
o Client Metadata Description: 클라이언트가 사용할 수 있는 OAuth
2.0 권한 부여 유형의 배열
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "response_types"
o Client Metadata Description: 클라이언트가 사용할 수 있는 OAuth
2.0 응답 유형의 배열
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "client_name"
o Client Metadata Description: 사용자에게 제시될, 사람이 읽을 수
있는 클라이언트 이름
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "client_uri"
o Client Metadata Description: 클라이언트에 관한 정보를 제공하는
웹 페이지의 URL
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "logo_uri"
o Client Metadata Description: 클라이언트의 로고를 참조하는 URL
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "scope"
o Client Metadata Description: OAuth 2.0 범위 값의 공백으로
구분된 목록
o Change Controller: IESG
o Specification Document(s): RFC 7591
Richer 등 표준 트랙 [25페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
o Client Metadata Name: "contacts"
o Client Metadata Description: 이 클라이언트에 책임이 있는
사람들에게 연락할 방법을 나타내는 문자열 배열로, 일반적으로
이메일 주소
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "tos_uri"
o Client Metadata Description: 클라이언트를 위한, 사람이 읽을 수
있는 서비스 약관 문서를 가리키는 URL
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "policy_uri"
o Client Metadata Description: 클라이언트를 위한, 사람이 읽을 수
있는 정책 문서를 가리키는 URL
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "jwks_uri"
o Client Metadata Description: 클라이언트의 공개 키를 나타내는
클라이언트의 JSON Web Key Set [RFC7517] 문서를 참조하는 URL
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "jwks"
o Client Metadata Description: 클라이언트의 공개 키를 나타내는
클라이언트의 JSON Web Key Set [RFC7517]
문서
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "software_id"
o Client Metadata Description: 클라이언트를 구성하는 소프트웨어의
식별자
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "software_version"
o Client Metadata Description: 클라이언트를 구성하는 소프트웨어의
버전 식별자
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "client_id"
o Client Metadata Description: 클라이언트 식별자
o Change Controller: IESG
o Specification Document(s): RFC 7591
Richer 등 표준 트랙 [26페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
o Client Metadata Name: "client_secret"
o Client Metadata Description: 클라이언트 시크릿
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "client_id_issued_at"
o Client Metadata Description: 클라이언트 식별자가 발급된 시각
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Client Metadata Name: "client_secret_expires_at"
o Client Metadata Description: 클라이언트 시크릿이 만료되는 시각
o Change Controller: IESG
o Specification Document(s): RFC 7591
4.2. OAuth 토큰 엔드포인트 인증 방법 레지스트리
이 명세는 "OAuth Token Endpoint Authentication Methods" 레지스트리를
설정한다.
"token_endpoint_auth_method" 값으로 사용할 추가 값은 하나 이상의
지정 전문가의 조언에 따라, oauth-ext-review@ietf.org 메일링
리스트에서 2주 검토 기간을 거친 뒤 Specification Required
([RFC5226])로 등록된다. 그러나 게시 전에 값을 할당할 수
있도록, 지정 전문가는 [RFC7120]에 따라 해당 명세가 게시될 것이라고
만족하면 등록을 승인할 수 있다.
등록 요청은 검토와 의견 수렴을 위해 적절한 제목(예: "Request
to register token_endpoint_auth_method value: example")과 함께
oauth-ext-review@ietf.org 메일링 리스트로 전송되어야 한다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고,
이 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명이
포함되어야 하며, 해당되는 경우 요청을 성공하게 만드는 방법에
대한 제안도 포함되어야 한다.
IANA는 지정 전문가로부터 온 레지스트리 업데이트만 수락해야
하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다.
Richer 등 표준 트랙 [27페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
4.2.1. 등록 템플릿
Token Endpoint Authentication Method Name:
요청된 이름(예: "example"). 이 이름은 대소문자를 구분한다.
대소문자를 구분하지 않는 방식으로 다른 등록된 이름과
일치하는 이름은 수락하지 않는 것이 바람직하다.
Change Controller:
표준 트랙 RFC의 경우 "IESG"를 나열한다. 그 외의 경우에는
책임 당사자의 이름을 제공한다. 기타 세부 정보(예: 우편
주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다.
Specification Document(s):
토큰 엔드포인트 인증 방법을 지정하는 문서 또는 문서들에
대한 참조이며, 가능한 경우 해당 문서의 사본을 가져오는 데
사용할 수 있는 URI를 포함한다. 관련 섹션의 표시도 포함될
수 있지만 필수는 아니다.
4.2.2. 초기 레지스트리 내용
"OAuth Token Endpoint Authentication Methods" 레지스트리의 초기
내용은 다음과 같다.
o Token Endpoint Authentication Method Name: "none"
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Token Endpoint Authentication Method Name: "client_secret_post"
o Change Controller: IESG
o Specification Document(s): RFC 7591
o Token Endpoint Authentication Method Name: "client_secret_basic"
o Change Controller: IESG
o Specification Document(s): RFC 7591
5. 보안 고려사항
클라이언트 등록 엔드포인트로의 요청은 (HTTP 요청과 응답에서)
평문 자격 증명의 전송을 초래하므로, 인가 서버는 등록
엔드포인트로 요청을 보낼 때 전송 계층 보안 메커니즘의 사용을
요구해야 한다. 서버는 TLS 1.2 [RFC5246]를 지원해야 하며,
자신의 보안 요구사항을 충족하는 추가 전송 계층 보안 메커니즘을
지원할 수 있다. TLS를 사용할 때, 클라이언트는 RFC 6125
[RFC6125]에 따라 TLS/SSL 서버 인증서 검사를 수행해야 한다.
구현 보안 고려사항은 Recommendations for Secure Use of TLS and
DTLS [BCP195]에서 찾을 수 있다.
Richer 등 표준 트랙 [28페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
"authorization_code" 및 "implicit"과 같은 리다이렉션 기반 권한
부여 유형을 사용하는 클라이언트에 대해, 인가 서버는 클라이언트가
자신의 리다이렉션 URI 값을 등록하도록 요구해야 한다. 이는
악의적 행위자가 유효하게 등록된 클라이언트에 끼어들어 이를
사칭하고, 유효하지 않은 리다이렉션 URI 또는 열린 리다이렉터를
통해 그 인가 코드나 토큰을 가로채는 공격을 완화하는 데 도움이
될 수 있다. 또한 리다이렉션 반환 값의 하이재킹을 방지하기
위해, 등록된 리다이렉션 URI 값은 다음 중 하나여야 한다.
o TLS로 보호되는 원격 웹 사이트
(예: https://client.example.com/oauth_redirect)
o HTTP URI를 사용하여 로컬 머신에 호스팅되는 웹 사이트
(예: http://localhost:8080/oauth_redirect)
o 클라이언트 애플리케이션에서만 사용할 수 있는 비 HTTP
애플리케이션별 URL
(예: exampleapp://oauth_redirect)
인가 서버의 정책이 허용하는 경우, 공개 클라이언트는 이
프로토콜을 사용해 인가 서버에 등록할 수 있다. 공개
클라이언트는 "token_endpoint_auth_method" 메타데이터 필드에
"none" 값을 사용하며 일반적으로 "implicit" 권한 부여 유형과
함께 사용된다. 이러한 클라이언트는 종종 사용자의 리소스에
대한 접근을 요청하는 단기 수명의 브라우저 내 애플리케이션이며,
접근은 인가 서버에서 사용자의 활성 세션과 연결된다. 이러한
클라이언트는 장기 저장소를 갖지 않는 경우가 많으므로,
브라우저 애플리케이션이 로드될 때마다 재등록해야 할 가능성이
있다. 그 결과로 죽은 클라이언트 식별자가 증식하는 것을
피하기 위해, 인가 서버는 일정 시간이 지난 뒤 특정 기준을
충족하는 기존 클라이언트의 등록을 만료시키기로 결정할 수 있다.
또는 이러한 클라이언트는 브라우저 내 애플리케이션 코드가
제공되는 서버에 등록될 수 있으며, 클라이언트의 구성은 코드와
함께 브라우저로 푸시될 수 있다.
서로 다른 OAuth 2.0 권한 부여 유형은 서로 다른 보안 및 사용
속성을 가지므로, 인가 서버는 여러 권한 부여 유형을 지원하는
소프트웨어 조각에 대해 별도의 등록을 요구할 수 있다. 예를
들어, 인가 서버는 "authorization_code" 권한 부여 유형을
사용하는 모든 클라이언트가 "token_endpoint_auth_method"에 대해
클라이언트 시크릿을 사용하도록 요구하되, "implicit" 권한 부여
유형을 사용하는 클라이언트는 토큰 엔드포인트에서 어떤 인증도
사용하지 않도록 요구할 수 있다. 이러한 상황에서 서버는
클라이언트가 "authorization_code"와 "implicit" 권한 부여 유형
둘 모두에 동시에 등록하는 것을 허용하지 않을 수 있다. 마찬가지로,
"authorization_code" 권한 부여 유형은 최종 사용자를 대신한
접근을 나타내는 데 사용되지만, "client_credentials" 권한 부여
유형은 클라이언트 자체를 대신한 접근을 나타낸다. 보안상의
이유로, 인가 서버는 이러한 서로 다른 사용 사례에 서로 다른
Richer 등 표준 트랙 [29페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
범위가 사용되도록 요구할 수 있으며, 그 결과 동일한 클라이언트가
이 두 권한 부여 유형을 함께 등록하는 것을 허용하지 않을 수
있다. 이러한 모든 경우에, 인가 서버는
"invalid_client_metadata" 오류 응답으로 응답하게 된다.
소프트웨어 명세서의 클레임으로 사용되는 경우가 아니라면, 인가
서버는 모든 클라이언트 메타데이터를 자체 주장된 것으로 취급해야
한다. 예를 들어, 악의적 클라이언트는 자신이 사칭하려는 합법적
클라이언트의 이름과 로고를 사용할 수 있다. 또한 악의적
클라이언트는 인가 서버에서 자신을 합법적 클라이언트의
인스턴스와 연결하려고, 합법적 클라이언트의 소프트웨어 식별자나
소프트웨어 버전을 사용하려고 시도할 수 있다. 이에 대응하기
위해, 인가 서버는 전체 등록 요청과 클라이언트 구성을 살펴봄으로써
이 위험을 완화하기 위한 적절한 조치를 취해야 한다. 예를 들어,
인가 서버는 로고의 도메인/사이트가 리다이렉션 URI의
도메인/사이트와 일치하지 않는 경우 경고를 발행할 수 있다.
또한 인가 서버는 다른 리다이렉션 URI나 다른 클라이언트 URI를
요청하는 알려진 소프트웨어 식별자의 등록 요청을 거부할 수
있다. 인가 서버는 모든 경우에 동적으로 등록된 클라이언트에
관해 최종 사용자에게 경고 메시지를 표시할 수도 있으며, 특히
그러한 클라이언트가 최근에 등록되었거나 인가 서버의 어떤
사용자에게도 이전에 신뢰받은 적이 없는 경우에는 더욱 그렇다.
인가 서버가 공개 클라이언트 등록을 지원하는 상황에서는,
클라이언트가 제공하고 사용자에게 표시될 모든 URL(예:
"logo_uri", "tos_uri", "client_uri", "policy_uri")을 매우
신중하게 다뤄야 한다. 예를 들어, 악의적 클라이언트는
"policy_uri"에 drive-by download에 대한 참조가 있는 등록 요청을
지정하여, 사용자가 인가 중 그것을 클릭하도록 유도할 수 있다.
인가 서버는 "logo_uri", "tos_uri", "client_uri", "policy_uri"가
"redirect_uris" 배열에 정의된 것과 동일한 호스트 및 스킴을
가지는지, 그리고 이러한 모든 URI가 유효한 웹 페이지로
해석되는지 확인해야 한다. 이러한 URI 값은 인가 페이지에서
사용자에게 표시되도록 의도되므로, 인가 서버는 가능한 경우
해당 URL에 호스팅된 악성 콘텐츠로부터 사용자를 보호해야 한다.
예를 들어, 인가 페이지에서 사용자에게 URL을 제시하기 전에,
인가 서버는 URL에 호스팅된 콘텐츠를 다운로드하고, 악성코드
스캐너 및 블랙리스트 필터와 대조하여 콘텐츠를 확인하며, 해당
URL에 보안 콘텐츠와 비보안 콘텐츠가 혼합되어 있는지 여부를
판단하고, 기타 가능한 서버 측 완화 조치를 수행할 수 있다.
이러한 URL의 콘텐츠는 언제든지 변경될 수 있으며 인가 서버가
URL의 안전성에 대해 완전한 확신을 제공할 수는 없지만, 이러한
관행은 도움이 될 수 있다는 점에 유의한다. 이러한 종류의
위협을 추가로 완화하기 위해, 인가 서버는 URL 링크가 제3자에
의해 제공되었고, 주의해서 다루어야 하며, 인가 서버 자체에서
Richer 등 표준 트랙 [30페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
호스팅되지 않는다는 점을 사용자에게 경고할 수도 있다. 예를
들어, HTML 앵커에서 링크를 직접 제공하는 대신, 인가 서버는
사용자가 대상 URL로 계속 이동하도록 허용하기 전에 중간 경고
페이지로 사용자를 안내할 수 있다.
클라이언트는 등록 요청의 일부로 클라이언트 메타데이터를 인가
서버에 제시하기 위해 직접 JSON 객체와 JWT로 인코딩된 소프트웨어
명세서를 모두 사용할 수 있다. 소프트웨어 명세서는 암호학적으로
보호되며 명세서 발급자가 한 클레임을 나타내는 반면, JSON 객체는
클라이언트 또는 개발자가 직접 한 자체 주장 클레임을 나타낸다.
소프트웨어 명세서가 유효하고 허용 가능한 권한자(예: 소프트웨어
API 게시자)에 의해 서명된 경우, 소프트웨어 명세서 안의
클라이언트 메타데이터 값은 일반 JSON 객체에 제시된 메타데이터
값보다 우선해야 한다. 일반 JSON 객체는 가로채어 수정되었을 수
있기 때문이다.
모든 메타데이터 값과 마찬가지로, 소프트웨어 명세서는 그 내용이
소프트웨어 명세서의 발급자에 의해 디지털 서명되었거나 MAC이
적용되었더라도 클라이언트가 자체 주장하는 항목이다. 따라서
대부분의 경우 소프트웨어 명세서를 제시하는 것만으로는 클라이언트
소프트웨어 조각을 완전히 식별하기에 충분하지 않다. 반대로,
초기 액세스 토큰은 특정 클라이언트 소프트웨어 조각에 관한
정보를 반드시 포함하지는 않으며, 대신 등록 엔드포인트를 사용할
권한을 나타낸다. 인가 서버는 특정 등록 요청을 존중할지 결정할
때 소프트웨어 명세서, 초기 액세스 토큰, JSON 클라이언트
메타데이터 값을 포함한 전체 등록 요청을 고려해야 한다.
인가 서버가 동시에 여러 인스턴스를 등록하도록 의도되지 않은
클라이언트에 대한 등록 요청을 받고, 인가 서버가 등록의 중복을
추론할 수 있는 경우(예: 기존의 다른 클라이언트와 동일한
"software_id" 및 "software_version" 값을 사용하는 경우), 서버는
새 등록을 의심스러운 것으로 취급하고 등록을 거부해야 한다.
새 클라이언트가 사용자를 속여 자신을 인가하도록 하기 위해 기존
클라이언트를 사칭하려는 것일 수도 있고, 원래 등록이 더 이상
유효하지 않을 수도 있다. 이 상황을 관리하는 세부 사항은 인가
서버 배포에 고유하며 이 명세의 범위를 벗어난다.
클라이언트 식별자는 인가 엔드포인트에서 클라이언트를 사칭하는 데
사용될 수 있는 공개 값이므로, 등록된 클라이언트의 여러
인스턴스에 동일한 클라이언트 식별자를 발급하기로 결정한 인가
서버는 이것이 발생하는 상황에 대해 매우 엄격해야 한다. 예를
들어, 인가 서버는 특정 클라이언트 식별자를 동일한 리다이렉션
기반 흐름과 동일한 리다이렉션 URI를 사용하는 클라이언트로
Richer 등 표준 트랙 [31페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
제한할 수 있다. 인가 서버는 등록된 클라이언트의 여러
인스턴스에 동일한 클라이언트 식별자가 발급되더라도, 동일한
클라이언트 시크릿을 발급해서는 안 된다. 그렇지 않으면 클라이언트
시크릿이 유출되어 악의적 사칭자가 기밀 클라이언트를 사칭할 수
있다.
6. 프라이버시 고려사항
이 명세에서 설명하는 프로토콜은 거의 전적으로 사람에 관한
정보가 아니라 소프트웨어에 관한 정보를 다루므로, 사용과 관련한
프라이버시 우려는 매우 적다. 주목할 만한 예외는 섹션 2에
정의된 "contacts" 필드로, 클라이언트 소프트웨어에 책임이 있는
개발자 또는 기타 당사자의 연락처 정보를 포함한다. 이러한
값은 최종 사용자에게 표시되도록 의도되며 인가 서버의 관리자에게
제공된다. 따라서 개발자는 개인 또는 업무용 주소를 사용하는
대신, 클라이언트 지원 목적에 명시적으로 전용된 이메일 주소나
기타 연락처 정보를 제공하기를 원할 수 있다. 또는 개발자가
떠나고 다른 사람이 그 책임을 맡은 뒤에도 클라이언트 소프트웨어에
대한 지속적인 연락과 지원이 가능하도록, 개발자는 클라이언트를
위한 공동 이메일 주소를 제공하기를 원할 수 있다.
일반적으로 클라이언트 이름 및 소프트웨어 식별자와 같은
클라이언트의 메타데이터는 클라이언트 소프트웨어 조각의 모든
인스턴스에서 공통이므로 최종 사용자에게 프라이버시 문제를
일으키지 않는다. 반면, 클라이언트 식별자는 종종 클라이언트의
특정 인스턴스에 고유하다. 많은 사용자가 사용하는 웹 사이트와
같은 클라이언트의 경우 클라이언트 식별자에 관한 프라이버시
우려가 크지 않을 수 있지만, 단일 최종 사용자의 기기에 설치된
네이티브 애플리케이션과 같은 클라이언트의 경우 클라이언트
식별자가 OAuth 2.0 트랜잭션 중 고유하게 추적될 수 있고 그
사용이 해당 단일 최종 사용자와 연결될 수 있다. 그러나
클라이언트 소프트웨어는 여전히 OAuth 2.0 인가 권한 부여를 통해
리소스 소유자에 의해 인가되어야 하므로, 이런 유형의 추적은
인증된 리소스 소유자와 요청 클라이언트 식별자를 상관시킴으로써
클라이언트 식별자가 고유한지 여부와 관계없이 발생할 수 있다.
이 명세는 클라이언트가 자체 클라이언트 식별자를 생성하는 것을
금지한다는 점에 유의한다. 클라이언트가 그렇게 할 수 있다면,
개별 클라이언트 인스턴스가 여러 공모하는 인가 서버에 걸쳐
추적되어 프라이버시 및 보안 문제가 발생할 수 있다. 또한
클라이언트 식별자는 일반적으로 동일한 소프트웨어 인스턴스에
대해서도 등록 요청별로 고유하게 발급된다. 이런 방식으로,
애플리케이션은 여러 번 등록하고 완전히 별개의 애플리케이션처럼
Richer 등 표준 트랙 [32페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
보임으로써 프라이버시를 약간 개선할 수 있다. 그러나 이 기법은
리소스 소유자별로 여러 번의 인가를 요구하는 형태로 상당한
사용성 비용을 수반하므로 실제로 사용될 가능성은 낮다.
7. 참고 문헌
7.1. 규범적 참고 문헌
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, 2015년 5월,
<http://www.rfc-editor.org/info/bcp195>.
[IANA.Language]
IANA, "Language Subtag Registry",
<http://www.iana.org/assignments/
language-subtag-registry>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008년 5월,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, 2008년 8월,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
2009년 9월, <http://www.rfc-editor.org/info/rfc5646>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, 2011년 3월,
<http://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, 2012년 10월,
<http://www.rfc-editor.org/info/rfc6749>.
Richer 등 표준 트랙 [33페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, 2012년 10월,
<http://www.rfc-editor.org/info/rfc6750>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, 2014년 1월,
<http://www.rfc-editor.org/info/rfc7120>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 2014년 3월,
<http://www.rfc-editor.org/info/rfc7159>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7519>.
[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security
Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
Client Authentication and Authorization Grants", RFC 7522,
DOI 10.17487/RFC7522, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7522>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, 2015년 5월,
<http://www.rfc-editor.org/info/rfc7523>.
Richer 등 표준 트랙 [34페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
7.2. 정보성 참고 문헌
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", 2014년 11월,
<http://openid.net/specs/
openid-connect-discovery-1_0.html>.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0", 2014년 11월,
<http://openid.net/specs/
openid-connect-registration-1_0.html>.
[RFC7592] Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management
Protocol", RFC 7592, DOI 10.17487/RFC7592, 2015년 7월,
<http://www.rfc-editor.org/info/rfc7592>.
[UMA-Core]
Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", 진행
중인 작업, draft-hardjono-oauth-umacore-13, 2015년 4월.
Richer 등 표준 트랙 [35페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
부록 A. 사용 사례
이 부록은 이 명세를 활용할 수 있는 여러 방식을 설명하며,
여기에는 선택해야 할 수 있는 일부 선택 사항의 설명도 포함된다.
일부 선택 사항은 독립적이며 조합하여 사용할 수 있는 반면,
일부 선택 사항은 서로 관련되어 있다.
A.1. 공개 동적 클라이언트 등록과 보호된 동적 클라이언트 등록
A.1.1. 공개 동적 클라이언트 등록
공개 등록을 지원하는 인가 서버는 초기 액세스 토큰 없이 등록이
이루어지도록 허용한다. 이를 통해 모든 클라이언트 소프트웨어가
인가 서버에 등록할 수 있다.
A.1.2. 보호된 동적 클라이언트 등록
보호된 등록을 지원하는 인가 서버는 등록 요청을 할 때 초기
액세스 토큰이 사용될 것을 요구한다. 클라이언트 또는 개발자가
이 초기 액세스 토큰을 받는 방법과 인가 서버가 이 초기 액세스
토큰을 검증하는 방법은 이 명세의 범위를 벗어나지만, 일반적인
접근 방식은 개발자가 인가 서버의 수동 사전 등록 포털을 사용하여
개발자에게 초기 액세스 토큰을 발급받는 것이다.
A.2. 소프트웨어 명세서 없이 또는 사용한 등록
A.2.1. 소프트웨어 명세서 없는 등록
등록 요청에서 소프트웨어 명세서가 사용되지 않는 경우, 인가
서버는 클라이언트 메타데이터 값이 어떤 권한자에 의해서도 디지털
서명되거나 MAC이 적용되지 않은(따라서 증명되지 않은) 상태로
사용될 수 있음을 받아들여야 한다. (이 선택은 공개 대 보호
선택과 독립적이며, 초기 액세스 토큰이 또 다른 가능한 증명
형태라는 점에 유의한다.)
A.2.2. 소프트웨어 명세서를 사용한 등록
소프트웨어 명세서는 클라이언트 메타데이터 값 집합에 대해
권한자의 증명을 제공하기 위해 등록 요청에서 사용될 수 있다.
이는 인가 서버가 특정 권한자 집합에 의해 증명된 클라이언트
소프트웨어로 등록을 제한하려는 경우 또는 여러 등록 요청이
동일한 클라이언트 소프트웨어 조각을 가리킨다는 것을 알고자
하는 경우 유용할 수 있다.
Richer 등 표준 트랙 [36페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
A.3. 클라이언트 또는 개발자에 의한 등록
A.3.1. 클라이언트에 의한 등록
일부 사용 사례에서는, 클라이언트 소프트웨어가 인가 서버와
상호작용하는 데 필요한 클라이언트 식별자 및 기타 정보를 얻기
위해 인가 서버에 자신을 동적으로 등록한다. 이 경우 인가 서버에
대한 클라이언트 식별자는 클라이언트 소프트웨어에 포함되어 있지
않다.
A.3.2. 개발자에 의한 등록
어떤 경우에는, 개발자(또는 개발자가 사용하는 개발 소프트웨어)가
인가 서버 또는 인가 서버 집합에 클라이언트 소프트웨어를 사전
등록한다. 이 경우 인가 서버(들)에 대한 클라이언트 식별자
값(들)은 클라이언트 소프트웨어에 포함될 수 있다.
A.4. 클라이언트 인스턴스별 또는 클라이언트 소프트웨어별 클라이언트 ID
A.4.1. 클라이언트 소프트웨어 인스턴스별 클라이언트 ID
어떤 경우에는, 클라이언트 소프트웨어 조각의 각 배포된
인스턴스가 동적으로 등록하여 서로 다른 클라이언트 식별자 값을
얻는다. 예를 들어 코드 흐름이 사용되는 경우, 이는 각
클라이언트 인스턴스가 자신만의 클라이언트 시크릿을 가질 수 있게
하므로 유리할 수 있다. 이는 소프트웨어와 함께 포함된
클라이언트 시크릿 값의 비밀성을 유지할 수는 없지만 인스턴스별
클라이언트 시크릿의 비밀성은 유지할 수 있는 네이티브
클라이언트에 유용할 수 있다.
A.4.2. 클라이언트 소프트웨어의 모든 인스턴스 간에 공유되는 클라이언트 ID
어떤 경우에는, 클라이언트 소프트웨어 조각의 각 배포된
인스턴스가 공통 클라이언트 식별자 값을 공유한다. 예를 들어,
이는 클라이언트 시크릿이 관여하지 않는 암시적 흐름을 사용하는
브라우저 내 클라이언트에서 자주 해당된다. 특정 인가 서버는
예를 들어 소프트웨어 명세서 값과 클라이언트 식별자 값 사이의
매핑을 유지하고, 특정 소프트웨어 조각에 대한 모든 등록 요청에
동일한 클라이언트 식별자 값을 반환하도록 선택할 수 있다. 인가
서버가 그렇게 하는 상황과 이 경우 요구되는 특정 소프트웨어
명세서 특성은 이 명세의 범위를 벗어난다.
Richer 등 표준 트랙 [37페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
A.5. 상태 저장 또는 무상태 등록
A.5.1. 상태 저장 클라이언트 등록
어떤 경우에는, 인가 서버가 일반적으로 클라이언트 식별자 값을
사용해 이 상태를 색인화하면서 등록된 클라이언트에 관한 상태를
유지한다. 이 상태에는 일반적으로 클라이언트 등록과 연결된
클라이언트 메타데이터 값과, 가능하면 인가 서버 구현에 특정한
다른 상태가 포함된다. 상태 저장 등록이 사용되는 경우, 이
상태의 검색 및/또는 업데이트를 지원하는 작업이 지원될 수 있다.
상태 저장 등록에 대한 가능한 작업 집합 하나는 [RFC7592]에
설명되어 있다.
A.5.2. 무상태 클라이언트 등록
어떤 경우에는, 인가 서버가 등록된 클라이언트에 관한 어떤 로컬
상태도 유지하지 않을 수 있는 방식으로 구현될 것이다. 이를
수행하는 한 가지 방법은 반환되는 클라이언트 식별자 값에 모든
등록 상태를 인코딩하고, 가능하면 상태의 기밀성과 무결성을
유지하기 위해 인가 서버에 대해 상태를 암호화하는 것이다.
감사의 말
저자들은 이 문서에 대한 의견을 제공한 OAuth Working Group,
User-Managed Access Working Group, OpenID Connect Working Group
참가자들에게 감사를 표한다. 특히 다음 개인들은 이 문서의
여러 초안 버전에 대한 검토와 기여에 중요한 역할을 했다:
Amanda Anganes, Derek Atkins, Tim Bray, Domenico Catalano, Donald
Coffin, Vladimir Dzhuvinov, George Fletcher, Thomas Hardjono, William
Kim, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony
Nadalin, Nat Sakimura, Christian Scholz, Hannes Tschofenig.
Richer 등 표준 트랙 [38페이지]
RFC 7591 OAuth 2.0 동적 등록 2015년 7월
저자 주소
Justin Richer (편집자)
Email: ietf@justin.richer.org
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
Maciej Machulak
Newcastle University
Email: maciej.machulak@gmail.com
Phil Hunt
Oracle Corporation
Email: phil.hunt@yahoo.com
Richer 등 표준 트랙 [39페이지]