인터넷 엔지니어링 태스크 포스 (IETF) M. Jones
의견 요청: 8414 Microsoft
분류: 표준 트랙 N. Sakimura
ISSN: 2070-1721 NRI
J. Bradley
Yubico
2018년 6월
OAuth 2.0 인가 서버 메타데이터
초록
이 명세는 OAuth 2.0 클라이언트가 OAuth 2.0 인가 서버와
상호 작용하는 데 필요한 정보를 얻기 위해 사용할 수 있는
메타데이터 형식을 정의하며, 여기에는 엔드포인트 위치와
인가 서버 기능이 포함된다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며
인터넷 엔지니어링 운영 그룹(IESG)에 의해 출판 승인을 받았다.
인터넷 표준에 대한 추가 정보는 RFC 7841의 Section 2에서 확인할 수 있다.
이 문서의 현재 상태, 정오표, 그리고 피드백 제공 방법에 대한
정보는 https://www.rfc-editor.org/info/rfc8414에서 얻을 수 있다.
Copyright Notice
Copyright (c) 2018 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
(https://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.
Jones, et al. 표준 트랙 [Page 1]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
목차
1. 소개 ..........................................................2
1.1. 요구사항 표기법 및 규약 ................................3
1.2. 용어 ....................................................3
2. 인가 서버 메타데이터 ..........................................4
2.1. 서명된 인가 서버 메타데이터 .............................8
3. 인가 서버 메타데이터 얻기 .....................................8
3.1. 인가 서버 메타데이터 요청 ...............................9
3.2. 인가 서버 메타데이터 응답 ..............................10
3.3. 인가 서버 메타데이터 검증 ..............................11
4. 문자열 작업 ..................................................11
5. 호환성 참고 사항 .............................................11
6. 보안 고려사항 ................................................12
6.1. TLS 요구사항 ............................................12
6.2. 사칭 공격 ...............................................12
6.3. 표준 형식으로 메타데이터 게시 ..........................13
6.4. 보호되는 리소스 .........................................13
7. IANA 고려사항 ................................................14
7.1. OAuth 인가 서버 메타데이터 레지스트리 ...................14
7.1.1. 등록 템플릿 .....................................15
7.1.2. 초기 레지스트리 내용 ............................16
7.2. 갱신된 등록 지침 ........................................19
7.3. Well-Known URI 레지스트리 ...............................19
7.3.1. 레지스트리 내용 .................................19
8. 참고문헌 .....................................................20
8.1. 규범적 참고문헌 .........................................20
8.2. 정보성 참고문헌 .........................................22
감사의 말 ......................................................23
저자 주소 ......................................................23
1. 소개
이 명세는 "OpenID Connect Discovery 1.0" [OpenID.Discovery]에서
정의한 메타데이터 형식을 일반화하여, OpenID Connect Discovery와
호환되면서 더 넓은 OAuth 2.0 사용 사례 집합에 적용할 수 있게
한다. 이는 "OAuth 2.0 Dynamic Client Registration Protocol"
[RFC7591]이 "OpenID Connect Dynamic Client Registration 1.0"
[OpenID.Registration]에서 정의한 동적 클라이언트 등록
메커니즘을 호환 가능한 방식으로 일반화한 것과 의도적으로
병렬을 이룬다.
인가 서버에 대한 메타데이터는 잘 알려진 위치에서 JSON
[RFC8259] 문서로 검색되며, 이 문서는 엔드포인트 위치와
인가 서버 기능을 선언한다. 이 과정은 Section 3에서 설명한다.
Jones, et al. 표준 트랙 [Page 2]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
이 메타데이터는 서버 오리진이 HTTPS를 통해 자기 주장 방식으로
전달할 수도 있고, JSON Web Token(JWT) [JWT] 안의 클레임으로
표현되는 서명된 메타데이터 값 집합으로 전달할 수도 있다. JWT
경우에는 issuer가 인가 서버에 대한 데이터의 유효성을 보증한다.
이는 OAuth Dynamic Client Registration [RFC7591]에서
Software Statement가 수행하는 역할과 유사하다.
클라이언트가 인가 서버를 선택하는 수단은 범위 밖이다. 어떤
경우에는 issuer 식별자가 클라이언트에 수동으로 구성될 수 있다.
다른 경우에는 예를 들어 "OpenID Connect Discovery 1.0"
[OpenID.Discovery]의 Section 2에 설명된 것처럼 WebFinger
[RFC7033] 사용을 통해 동적으로 발견될 수 있다.
1.1. 요구사항 표기법 및 규약
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", 그리고 "OPTIONAL"은 여기에 표시된
것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119]
[RFC8174]에 설명된 대로 해석되어야 한다.
이 명세에서 JSON Web Signature(JWS) [JWS] 및 JSON Web
Encryption(JWE) [JWE] 데이터 구조를 사용하는 모든 경우에는 JWS
Compact Serialization 또는 JWE Compact Serialization을 사용한다.
JWS JSON Serialization 및 JWE JSON Serialization은 사용하지
않는다.
1.2. 용어
이 명세는 OAuth 2.0 [RFC6749]에서 정의한 "Access Token",
"Authorization Code", "Authorization Endpoint", "Authorization
Grant", "Authorization Server", "Client", "Client Authentication",
"Client Identifier", "Client Secret", "Grant Type", "Protected
Resource", "Redirection URI", "Refresh Token", "Resource Owner",
"Resource Server", "Response Type", 그리고 "Token Endpoint"라는
용어, JSON Web Token(JWT) [JWT]에서 정의한 "Claim Name",
"Claim Value", "JSON Web Token (JWT)"이라는 용어, 그리고
"OAuth 2.0 Multiple Response Type Encoding Practices"
[OAuth.Responses]에서 정의한 "Response Mode"라는 용어를
사용한다.
Jones, et al. 표준 트랙 [Page 3]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
2. 인가 서버 메타데이터
인가 서버는 자신의 구성을 설명하는 메타데이터를 가질 수 있다.
다음 인가 서버 메타데이터 값들은 이 명세에서 사용되며,
Section 7.1에서 수립한 IANA "OAuth Authorization Server
Metadata" 레지스트리에 등록된다.
issuer
REQUIRED. 인가 서버의 issuer 식별자이며, "https" 스킴을
사용하고 query 또는 fragment 구성요소가 없는 URL이다. 인가
서버 메타데이터는 Section 3에 설명된 것처럼 이 issuer
식별자로부터 파생된, RFC 5785 [RFC5785]에 따른
".well-known" 위치에 게시된다. issuer 식별자는 "OAuth 2.0
Mix-Up Mitigation" [MIX-UP]에 설명된 것처럼 인가 서버
mix-up 공격을 방지하는 데 사용된다.
authorization_endpoint
인가 서버의 authorization endpoint [RFC6749]의 URL이다.
authorization endpoint를 사용하는 grant type이 지원되지 않는
경우가 아니라면 REQUIRED이다.
token_endpoint
인가 서버의 token endpoint [RFC6749]의 URL이다. implicit
grant type만 지원되는 경우가 아니라면 REQUIRED이다.
jwks_uri
OPTIONAL. 인가 서버의 JWK Set [JWK] 문서의 URL이다. 참조된
문서는 클라이언트가 인가 서버의 서명을 검증하는 데 사용하는
서명 키를 포함한다. 이 URL은 "https" 스킴을 사용해야 한다.
JWK Set은 클라이언트가 서버로 요청을 암호화하는 데 사용하는
서버의 암호화 키도 포함할 수 있다. 서명 키와 암호화 키가
모두 제공되는 경우, 참조된 JWK Set의 모든 키에는 각 키의
의도된 용도를 나타내기 위한 "use"(public key use) 파라미터
값이 REQUIRED이다.
registration_endpoint
OPTIONAL. 인가 서버의 OAuth 2.0 Dynamic Client Registration
endpoint [RFC7591]의 URL이다.
scopes_supported
RECOMMENDED. 이 인가 서버가 지원하는 OAuth 2.0 [RFC6749]
"scope" 값 목록을 포함하는 JSON 배열이다. 서버는 이 파라미터를
사용하더라도 지원되는 일부 scope 값을 광고하지 않도록 선택할
수 있다.
Jones, et al. 표준 트랙 [Page 4]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
response_types_supported
REQUIRED. 이 인가 서버가 지원하는 OAuth 2.0 "response_type"
값 목록을 포함하는 JSON 배열이다. 사용되는 배열 값은
"OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]에서
정의한 "response_types" 파라미터에 사용되는 값과 동일하다.
response_modes_supported
OPTIONAL. "OAuth 2.0 Multiple Response Type Encoding Practices"
[OAuth.Responses]에 명시된 대로, 이 인가 서버가 지원하는
OAuth 2.0 "response_mode" 값 목록을 포함하는 JSON 배열이다.
생략하면 기본값은 "["query", "fragment"]"이다. response mode
값 "form_post"도 "OAuth 2.0 Form Post Response Mode"
[OAuth.Post]에서 정의한다.
grant_types_supported
OPTIONAL. 이 인가 서버가 지원하는 OAuth 2.0 grant type 값
목록을 포함하는 JSON 배열이다. 사용되는 배열 값은 "OAuth 2.0
Dynamic Client Registration Protocol" [RFC7591]에서 정의한
"grant_types" 파라미터에 사용되는 값과 동일하다. 생략하면
기본값은 "["authorization_code", "implicit"]"이다.
token_endpoint_auth_methods_supported
OPTIONAL. 이 token endpoint가 지원하는 client authentication
method 목록을 포함하는 JSON 배열이다. client authentication
method 값은 [RFC7591]의 Section 2에서 정의한
"token_endpoint_auth_method" 파라미터에 사용된다. 생략하면
기본값은 OAuth 2.0 [RFC6749]의 Section 2.3.1에 명시된 HTTP Basic
Authentication Scheme인 "client_secret_basic"이다.
token_endpoint_auth_signing_alg_values_supported
OPTIONAL. "private_key_jwt" 및 "client_secret_jwt" 인증
메서드에 대해 token endpoint에서 클라이언트를 인증하는 데
사용되는 JWT [JWT]의 서명에 대해 token endpoint가 지원하는 JWS
서명 알고리즘("alg" 값) 목록을 포함하는 JSON 배열이다. 이
메타데이터 항목은 이러한 인증 메서드 중 하나가
"token_endpoint_auth_methods_supported" 항목에 지정되어 있는
경우 반드시 존재해야 한다. 이 항목이 생략되면 기본 알고리즘은
암시되지 않는다. 서버는 "RS256"을 지원하는 것이 좋다. 값
"none"은 사용해서는 안 된다.
service_documentation
OPTIONAL. 개발자가 인가 서버를 사용할 때 알고 싶어 하거나
알아야 할 수 있는 사람이 읽을 수 있는 정보를 포함하는 페이지의
URL이다. 특히 인가 서버가 Dynamic Client Registration을
Jones, et al. 표준 트랙 [Page 5]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
지원하지 않는다면, 클라이언트를 등록하는 방법에 대한 정보를 이
문서에서 제공해야 한다.
ui_locales_supported
OPTIONAL. 사용자 인터페이스에 대해 지원되는 언어와 문자 체계를
BCP 47 [RFC5646]의 language tag 값 JSON 배열로 표현한 것이다.
생략하면 지원되는 언어 및 문자 체계 집합은 명시되지 않는다.
op_policy_uri
OPTIONAL. 인가 서버가 클라이언트를 등록하는 사람에게 제공하는
URL로, 클라이언트가 인가 서버가 제공하는 데이터를 어떻게 사용할
수 있는지에 대한 인가 서버의 요구사항을 읽기 위한 것이다.
등록 과정은 이 URL이 제공된 경우 클라이언트를 등록하는 사람에게
이 URL을 표시하는 것이 좋다. Section 5에 설명된 것처럼
식별자 "op_policy_uri"가 OpenID 전용처럼 보이지만, 이
명세에서의 사용은 실제로 OpenID Connect에 한정되지 않는
일반적인 OAuth 2.0 기능을 가리킨다.
op_tos_uri
OPTIONAL. 인가 서버가 클라이언트를 등록하는 사람에게 제공하는
URL로, 인가 서버의 서비스 약관을 읽기 위한 것이다. 등록 과정은
이 URL이 제공된 경우 클라이언트를 등록하는 사람에게 이 URL을
표시하는 것이 좋다. Section 5에 설명된 것처럼 식별자
"op_tos_uri"가 OpenID 전용처럼 보이지만, 이 명세에서의 사용은
실제로 OpenID Connect에 한정되지 않는 일반적인 OAuth 2.0
기능을 가리킨다.
revocation_endpoint
OPTIONAL. 인가 서버의 OAuth 2.0 revocation endpoint
[RFC7009]의 URL이다.
revocation_endpoint_auth_methods_supported
OPTIONAL. 이 revocation endpoint가 지원하는 client
authentication method 목록을 포함하는 JSON 배열이다. 유효한
client authentication method 값은 IANA "OAuth Token Endpoint
Authentication Methods" 레지스트리 [IANA.OAuth.Parameters]에
등록된 값이다. 생략하면 기본값은 OAuth 2.0 [RFC6749]의
Section 2.3.1에 명시된 HTTP Basic Authentication Scheme인
"client_secret_basic"이다.
revocation_endpoint_auth_signing_alg_values_supported
OPTIONAL. revocation endpoint에서 "private_key_jwt" 및
"client_secret_jwt" 인증 메서드에 대해 클라이언트를 인증하는
데 사용되는 JWT [JWT]의 서명에 대해 revocation endpoint가
Jones, et al. 표준 트랙 [Page 6]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
지원하는 JWS 서명 알고리즘("alg" 값) 목록을 포함하는 JSON
배열이다. 이 메타데이터 항목은 이러한 인증 메서드 중 하나가
"revocation_endpoint_auth_methods_supported" 항목에 지정되어
있는 경우 반드시 존재해야 한다. 이 항목이 생략되면 기본
알고리즘은 암시되지 않는다. 값 "none"은 사용해서는 안 된다.
introspection_endpoint
OPTIONAL. 인가 서버의 OAuth 2.0 introspection endpoint
[RFC7662]의 URL이다.
introspection_endpoint_auth_methods_supported
OPTIONAL. 이 introspection endpoint가 지원하는 client
authentication method 목록을 포함하는 JSON 배열이다. 유효한
client authentication method 값은 IANA "OAuth Token Endpoint
Authentication Methods" 레지스트리 [IANA.OAuth.Parameters]에
등록된 값 또는 IANA "OAuth Access Token Types" 레지스트리
[IANA.OAuth.Parameters]에 등록된 값이다. (이 값들은
Section 7.2 때문에 서로 구별되며 앞으로도 구별된 상태로
유지된다.) 생략하면 지원되는 인증 메서드 집합은 다른 수단으로
결정되어야 한다.
introspection_endpoint_auth_signing_alg_values_supported
OPTIONAL. introspection endpoint에서 "private_key_jwt" 및
"client_secret_jwt" 인증 메서드에 대해 클라이언트를 인증하는
데 사용되는 JWT [JWT]의 서명에 대해 introspection endpoint가
지원하는 JWS 서명 알고리즘("alg" 값) 목록을 포함하는 JSON
배열이다. 이 메타데이터 항목은 이러한 인증 메서드 중 하나가
"introspection_endpoint_auth_methods_supported" 항목에 지정되어
있는 경우 반드시 존재해야 한다. 이 항목이 생략되면 기본
알고리즘은 암시되지 않는다. 값 "none"은 사용해서는 안 된다.
code_challenge_methods_supported
OPTIONAL. 이 인가 서버가 지원하는 Proof Key for Code Exchange
(PKCE) [RFC7636] code challenge method 목록을 포함하는 JSON
배열이다. Code challenge method 값은 [RFC7636]의
Section 4.3에서 정의한 "code_challenge_method" 파라미터에
사용된다. 유효한 code challenge method 값은 IANA "PKCE Code
Challenge Methods" 레지스트리 [IANA.OAuth.Parameters]에 등록된
값이다. 생략하면 인가 서버는 PKCE를 지원하지 않는다.
추가 인가 서버 메타데이터 파라미터도 사용될 수 있다. 일부는
OpenID Connect Discovery 1.0 [OpenID.Discovery]과 같은 다른
명세에서 정의된다.
Jones, et al. 표준 트랙 [Page 7]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
2.1. 서명된 인가 서버 메타데이터
JSON 요소 외에도, 메타데이터 값은 인가 서버에 대한 메타데이터
값을 하나의 묶음으로 주장하는 JSON Web Token(JWT) [JWT]인
"signed_metadata" 값으로 제공될 수도 있다. 서명된 메타데이터에서
사용할 수 있는 클레임 집합은 Section 2에서 정의된다. 서명된
메타데이터는 JSON Web Signature(JWS) [JWS]를 사용하여 디지털
서명되거나 MAC되어야 하며, 서명된 메타데이터의 클레임을 증명하는
당사자를 나타내는 "iss"(issuer) 클레임을 반드시 포함해야 한다.
메타데이터 소비자는 이 기능을 지원하지 않는 경우 서명된
메타데이터를 무시할 수 있다. 메타데이터 소비자가 서명된
메타데이터를 지원하는 경우, 서명된 메타데이터로 전달되는
메타데이터 값은 일반 JSON 요소를 사용하여 전달되는 해당 값보다
우선해야 한다.
서명된 메타데이터는 이 OPTIONAL 멤버를 사용하여 인가 서버
메타데이터 JSON 객체에 포함된다.
signed_metadata
인가 서버에 대한 메타데이터 값을 클레임으로 포함하는 JWT이다.
이는 전체 서명된 JWT로 구성된 문자열 값이다. "signed_metadata"
메타데이터 값은 JWT의 클레임으로 나타나지 않는 것이 좋다.
3. 인가 서버 메타데이터 얻기
메타데이터를 지원하는 인가 서버는 Section 2에 명시된
메타데이터를 포함하는 JSON 문서를, well-known URI 문자열을 인가
서버의 issuer 식별자 안에서 host 구성요소와 path 구성요소(있는
경우) 사이에 삽입하여 형성한 경로에서 제공해야 한다. 기본적으로
사용되는 well-known URI 문자열은
"/.well-known/oauth-authorization-server"이다. 이 경로는 "https"
스킴을 사용해야 한다. ".well-known"의 문법과 의미는 RFC 5785
[RFC5785]에서 정의된다. 사용되는 well-known URI suffix는 IANA
"Well-Known URIs" 레지스트리 [IANA.well-known]에 등록되어야
한다.
OAuth 인가 서버를 애플리케이션별 방식으로 활용하는 서로 다른
애플리케이션은 해당 애플리케이션에서 사용하는 인가 서버
메타데이터를 게시하기 위해 서로 다른 well-known URI suffix를
정의하고 등록할 수 있다. 예를 들어 예시 애플리케이션이 OAuth
인가 서버를 예시 전용 방식으로 사용하고, 게시해야 하는 예시 전용
메타데이터 값이 있다면, "example-configuration" URI suffix를
등록하고 사용하여 인가 서버의 issuer 식별자에서 host와 path
구성요소 사이에 "/.well-known/example-configuration"을 삽입하여
형성한 경로에 메타데이터 문서를 게시할 수 있다. 또는 이러한
애플리케이션 다수는 일반 목적 OAuth 인가 서버에 올바른 선택인
Jones, et al. 표준 트랙 [Page 8]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
기본 well-known URI 문자열 "/.well-known/oauth-authorization-server"를
사용하고, 애플리케이션 전용 문자열은 등록하지 않을 것이다.
이 명세를 사용하는 OAuth 2.0 애플리케이션은 이 목적을 위해 어떤
well-known URI suffix를 사용할지 명시해야 한다. 동일한 인가
서버는 자신의 issuer 식별자로부터 파생된 여러 well-known 위치에
메타데이터를 게시하도록 선택할 수 있으며, 예를 들어
"/.well-known/example-configuration"과
"/.well-known/oauth-authorization-server" 양쪽 모두에 메타데이터를
게시할 수 있다.
일부 OAuth 애플리케이션은 well-known URI suffix
"openid-configuration"을 사용하도록 선택할 것이다. Section 5에
설명된 것처럼 식별자 "/.well-known/openid-configuration"이 OpenID
전용처럼 보이지만, 이 명세에서의 사용은 실제로 OpenID Connect에
한정되지 않는 일반적인 OAuth 2.0 기능을 가리킨다.
3.1. 인가 서버 메타데이터 요청
인가 서버 메타데이터 문서는 이전에 지정된 경로에서 HTTP "GET"
요청을 사용하여 질의해야 한다.
issuer 식별자가 "https://example.com"이고 well-known URI suffix가
"oauth-authorization-server"인 경우, issuer 식별자에 path
구성요소가 없으므로 클라이언트는 메타데이터를 얻기 위해 다음
요청을 수행한다.
GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com
issuer 식별자 값에 path 구성요소가 포함되어 있는 경우,
"/.well-known/" 및 well-known URI suffix를 host 구성요소와 path
구성요소 사이에 삽입하기 전에 끝의 "/"를 제거해야 한다. issuer
식별자가 "https://example.com/issuer1"이고 well-known URI suffix가
"oauth-authorization-server"인 경우, issuer 식별자에 path
구성요소가 포함되어 있으므로 클라이언트는 메타데이터를 얻기 위해
다음 요청을 수행한다.
GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com
path 구성요소를 사용하면 호스트당 여러 issuer를 지원할 수 있다.
이는 일부 멀티 테넌트 호스팅 구성에서 필요하다. 이 ".well-known"
사용은 호스트당 여러 issuer를 지원하기 위한 것이며, RFC 5785
[RFC5785]에서의 사용과 달리 호스트에 대한 일반 정보를 제공하지
않는다.
Jones, et al. 표준 트랙 [Page 9]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
3.2. 인가 서버 메타데이터 응답
응답은 필요한 모든 엔드포인트와 공개 키 위치 정보를 포함하여 인가
서버의 구성에 대한 클레임 집합이다. 성공 응답은 200 OK HTTP 상태
코드를 사용해야 하며, Section 2에서 정의한 메타데이터 값의
부분집합인 클레임 집합을 멤버로 포함하는 JSON 객체를
"application/json" 콘텐츠 타입으로 반환해야 한다. 다른 클레임도
반환될 수 있다.
여러 값을 반환하는 클레임은 JSON 배열로 표현된다. 요소가 0개인
클레임은 응답에서 생략되어야 한다.
오류 응답은 적용 가능한 HTTP 상태 코드 값을 사용한다.
다음은 비규범적 예시 응답이다.
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":
"https://server.example.com",
"authorization_endpoint":
"https://server.example.com/authorize",
"token_endpoint":
"https://server.example.com/token",
"token_endpoint_auth_methods_supported":
["client_secret_basic", "private_key_jwt"],
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"],
"userinfo_endpoint":
"https://server.example.com/userinfo",
"jwks_uri":
"https://server.example.com/jwks.json",
"registration_endpoint":
"https://server.example.com/register",
"scopes_supported":
["openid", "profile", "email", "address",
"phone", "offline_access"],
"response_types_supported":
["code", "code token"],
"service_documentation":
"http://server.example.com/service_documentation.html",
"ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}
Jones, et al. 표준 트랙 [Page 10]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
3.3. 인가 서버 메타데이터 검증
반환된 "issuer" 값은 메타데이터를 검색하는 데 사용된 URL을 만들기
위해 well-known URI 문자열이 삽입된 인가 서버의 issuer 식별자
값과 동일해야 한다. 이 값들이 동일하지 않으면 응답에 포함된
데이터는 사용되어서는 안 된다.
4. 문자열 작업
일부 OAuth 2.0 메시지를 처리하려면 메시지의 값을 알려진 값과
비교해야 한다. 예를 들어 메타데이터 응답의 멤버 이름을 "issuer"와
같은 특정 멤버 이름과 비교할 수 있다. 그러나 Unicode [UNICODE]
문자열 비교에는 중요한 보안 영향이 있다.
따라서 JSON 문자열과 기타 Unicode 문자열 사이의 비교는 아래에
명시된 대로 수행해야 한다.
1. JSON이 적용한 이스케이프를 제거하여 Unicode 코드 포인트
배열을 생성한다.
2. Unicode Normalization [USA15]은 JSON 문자열 또는 비교 대상
문자열 어느 쪽에도 어떤 시점에서도 적용해서는 안 된다.
3. 두 문자열 사이의 비교는 Unicode 코드 포인트 대 코드 포인트
동일성 비교로 수행해야 한다.
이는 [RFC8259]의 Section 8.3에 설명된 동일성 비교 절차와
같다는 점에 유의하라.
5. 호환성 참고 사항
식별자 "/.well-known/openid-configuration", "op_policy_uri", 그리고
"op_tos_uri"는 원래 "OpenID Connect Discovery 1.0"
[OpenID.Discovery]에서 정의된 OpenID Connect [OpenID.Core]
명세군을 가리키는 문자열을 포함한다. OpenID 전용처럼 보이는 이
식별자들을 재사용하더라도, 이 명세에서의 사용은 실제로 OpenID
Connect에 한정되지 않는 일반적인 OAuth 2.0 기능을 가리킨다.
Section 3에서 정의한 issuer 식별자를 인가 서버 메타데이터
위치로 변환하는 알고리즘은, issuer 식별자에 path 구성요소가
없다는 조건에서 "OpenID Connect Discovery 1.0"
[OpenID.Discovery]의 Section 4에 정의된 해당 변환과
동등하다. 그러나 path 구성요소가 있을 때는 서로 다르다. 왜냐하면
Jones, et al. 표준 트랙 [Page 11]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
OpenID Connect Discovery 1.0은 well-known URI 문자열이 issuer
식별자 뒤에 추가된다고 명시하지만(예:
"https://example.com/issuer1/.well-known/openid-configuration"),
이 명세는 well-known URI 문자열이 issuer 식별자의 path 구성요소
앞에 삽입된다고 명시하기 때문이다(예:
"https://example.com/.well-known/openid-configuration/issuer1").
앞으로 OAuth 인가 서버 메타데이터 위치는 이 명세에서 정의한
변환을 사용하는 것이 좋다. 그러나 OpenID Connect Discovery 1.0
변환이 이미 사용되고 있는 기존 환경에 배포된 경우, 전환 기간
동안 path 구성요소를 포함하는 issuer 식별자에 대한 메타데이터를
두 위치 모두에 게시할 필요가 있을 수 있다. 이 전환 기간 동안
애플리케이션은 먼저 이 명세에서 정의한 변환을 적용하고 결과
위치에서 인가 서버 메타데이터 검색을 시도해야 한다. 그 위치에서
검색이 실패하는 경우에만 OpenID Connect Discovery 1.0에서 정의한
변환을 사용하여 얻은 대체 위치에서 검색을 시도해야 한다. 이
하위 호환 동작은 애플리케이션이 사용하는 well-known URI suffix가
"openid-configuration"인 경우에만 필요할 것이다.
6. 보안 고려사항
6.1. TLS 요구사항
구현은 TLS를 지원해야 한다. 어떤 버전을 구현해야 하는지는 시간이
지남에 따라, 그리고 구현 당시의 광범위한 배포 현황과 알려진 보안
취약점에 따라 달라진다. 인가 서버는 TLS 버전 1.2 [RFC5246]를
지원해야 하며, 보안 요구사항을 충족하는 추가 TLS 메커니즘을
지원할 수 있다. TLS를 사용할 때 클라이언트는 RFC 6125
[RFC6125]에 따라 TLS/SSL 서버 인증서 검사를 수행해야 한다.
구현 보안 고려사항은 "Recommendations for Secure Use of Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
[BCP195]에서 확인할 수 있다.
정보 공개와 변조를 방지하기 위해, 기밀성과 무결성 보호를
제공하는 cipher suite가 포함된 TLS를 사용하여 기밀성 보호를
적용해야 한다.
6.2. 사칭 공격
인가 서버 메타데이터 요청을 할 때, 클라이언트는 Section 6.1에
설명된 대로 TLS 인증서 검사를 수행해야 한다. 서버 인증서가
issuer 식별자 URL에 대해 유효한지 확인하면 중간자 공격 및 DNS
기반
Jones, et al. 표준 트랙 [Page 12]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
공격을 방지할 수 있다. 이러한 공격은 클라이언트가 공격자의 키와
엔드포인트를 사용하도록 속일 수 있으며, 이는 합법적인 인가 서버를
사칭할 수 있게 한다. 공격자가 이를 달성할 수 있다면, 사칭 중인
인가 서버를 사용해 영향을 받은 클라이언트가 접근 권한을 가진
리소스에 접근할 수 있다.
공격자는 또한 사칭 대상 인가 서버의 issuer 식별자 URL을 사용한
"issuer" 클레임을 포함하되, 자신의 엔드포인트와 서명 키를 포함한
메타데이터 문서를 게시함으로써 인가 서버를 사칭하려고 시도할 수
있다. 클라이언트가 이를 수락하면 공격자는 해당 인가 서버를
사칭할 수 있게 된다. 이를 방지하려면 클라이언트는 메타데이터
요청의 접두사로 사용하는 issuer 식별자 URL이 클라이언트가 받은
인가 서버 메타데이터 문서의 "issuer" 메타데이터 값과 정확히
일치하는지 확인해야 한다.
6.3. 표준 형식으로 메타데이터 게시
인가 서버에 대한 정보를 표준 형식으로 게시하면 합법적인
클라이언트와 공격자 모두가 인가 서버를 더 쉽게 사용할 수 있다.
인가 서버가 자체적인 방식으로 메타데이터를 게시하든, 이 명세에서
정의한 표준 형식으로 게시하든, 이 정보를 사용해 수행될 수 있는
공격에 대한 동일한 방어를 적용해야 한다.
6.4. 보호되는 리소스
모든 사용 사례에서 인가 서버와 함께 사용할 적절한 보호되는
리소스를 안전하게 결정하는 것은 이 명세의 범위 밖이다. 이 명세는
클라이언트가 인가 서버와 함께 사용할 적절한 보호되는 리소스를
결정할 수단을 가지고 있으며, 각 인가 서버에 대해 올바른
메타데이터를 사용하고 있다고 가정한다. 구현자는 클라이언트가
부적절한 보호되는 리소스를 사용하면 공격자가 인가 서버나
클라이언트에 탐지되지 않은 채 유효한 보호되는 리소스에 대한
중간자 프록시로 동작할 수 있을 수 있음을 알아야 한다.
인가 서버와 함께 사용할 적절한 보호되는 리소스를 결정하는 방법은
일반적으로 애플리케이션에 따라 달라진다. 예를 들어 일부 인가
서버는 고정된 보호되는 리소스 또는 보호되는 리소스 집합과 함께
사용되며, 그 위치는 잘 알려져 있거나 인가 서버가 메타데이터
값으로 게시할 수 있다. 다른 경우에는 인가 서버와 함께 사용할 수
있는 리소스 집합이 관리 작업에 의해 동적으로 변경될 수 있다.
인가 서버와 보호되는 리소스 사이의 적절한 연관을 결정하는 여러
다른 수단도 가능하다.
Jones, et al. 표준 트랙 [Page 13]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
7. IANA 고려사항
다음 등록 절차는 이 명세가 수립한 레지스트리에 사용된다.
값은 oauth-ext-review@ietf.org 메일링 리스트에서 2주간 검토된
후, 한 명 이상의 Designated Expert의 조언에 따라 Specification
Required [RFC8126] 기준으로 등록된다. 그러나 출판 전에 값
할당을 허용하기 위해, Designated Expert는 그러한 명세가 출판될
것이라고 만족하는 경우 등록을 승인할 수 있다.
검토를 위해 메일링 리스트로 보내는 등록 요청은 적절한 제목을
사용해야 한다(예: "Request to register OAuth Authorization Server
Metadata: example").
검토 기간 내에 Designated Expert는 등록 요청을 승인하거나
거부하며, 이 결정을 검토 목록과 IANA에 전달한다. 거부에는 설명과,
적용 가능한 경우 요청을 성공시키는 방법에 대한 제안이 포함되어야
한다. 21일보다 긴 기간 동안 결정되지 않은 등록 요청은 해결을 위해
IESG의 주의로 가져갈 수 있다(iesg@ietf.org 메일링 리스트 사용).
Designated Expert가 적용해야 할 기준에는 제안된 등록이 기존
기능을 중복하는지 여부, 일반적으로 적용 가능할 가능성이 있는지
또는 단일 애플리케이션에만 유용한지 여부, 그리고 등록이 타당한지
여부를 판단하는 것이 포함된다.
IANA는 Designated Expert로부터의 레지스트리 갱신만 수락해야 하며,
모든 등록 요청을 검토 메일링 리스트로 안내해야 한다.
이 명세를 사용하는 서로 다른 애플리케이션의 관점을 대표할 수 있는
여러 Designated Expert를 임명하여, 등록 결정에 대한 폭넓은
정보를 바탕으로 한 검토가 가능하도록 하는 것이 제안된다. 특정
Designated Expert에게 등록 결정이 이해 상충을 만들 수 있다고
인식될 수 있는 경우, 해당 Designated Expert는 다른 Designated
Expert들의 판단에 맡겨야 한다.
7.1. OAuth 인가 서버 메타데이터 레지스트리
이 명세는 OAuth 2.0 인가 서버 메타데이터 이름을 위한 IANA
"OAuth Authorization Server Metadata" 레지스트리를 수립한다.
레지스트리는 인가 서버 메타데이터 멤버와 이를 정의하는 명세에
대한 참조를 기록한다.
Jones, et al. 표준 트랙 [Page 14]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
Designated Expert는 다음 중 하나를 해야 한다.
(a) 등록되는 메타데이터 이름과 값이 큰따옴표('"')와 백슬래시
('\')를 제외한 출력 가능한 ASCII 문자만 사용하도록 요구한다
(코드 포인트 U+0021, U+0023부터 U+005B까지, 그리고 U+005D부터
U+007E까지의 Unicode 문자), 또는
(b) 다른 코드 포인트를 사용하는 새 메타데이터 멤버나 값이
정의되는 경우, 그 정의가 이를 표현하는 데 사용되는 Unicode 코드
포인트의 정확한 시퀀스를 명시하도록 요구한다. 또한 JSON 문자열에서
이스케이프된 문자로만 표현될 수 있는 Unicode 코드 포인트를
사용하는 제안된 등록은 수락되어서는 안 된다.
7.1.1. 등록 템플릿
메타데이터 이름:
요청된 이름(예: "issuer"). 이 이름은 대소문자를 구분한다.
Designated Expert가 예외를 허용해야 할 설득력 있는 이유가
있다고 명시하지 않는 한, 이름은 대소문자를 구분하지 않는 방식
(Unicode toLowerCase() 연산을 두 문자열에 모두 적용하면 일치하게
되는 방식)으로 다른 등록된 이름과 일치해서는 안 된다.
메타데이터 설명:
메타데이터에 대한 간단한 설명(예: "Issuer identifier URL").
변경 관리자:
표준 트랙 RFC의 경우 "IESG"를 나열한다. 그 외의 경우에는
책임 당사자의 이름을 제공한다. 기타 세부사항(예: 우편 주소,
이메일 주소, 홈페이지 URI)도 포함할 수 있다.
명세 문서:
파라미터를 명시하는 문서 또는 문서들에 대한 참조이며, 문서
사본을 검색하는 데 사용할 수 있는 URI를 포함하는 것이 바람직하다.
관련 섹션 표시도 포함할 수 있지만 필수는 아니다.
Jones, et al. 표준 트랙 [Page 15]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
7.1.2. 초기 레지스트리 내용
o 메타데이터 이름: issuer
o 메타데이터 설명: 인가 서버의 issuer 식별자 URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: authorization_endpoint
o 메타데이터 설명: 인가 서버의 authorization endpoint URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: token_endpoint
o 메타데이터 설명: 인가 서버의 token endpoint URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: jwks_uri
o 메타데이터 설명: 인가 서버의 JWK Set 문서 URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: registration_endpoint
o 메타데이터 설명: 인가 서버의 OAuth 2.0 Dynamic Client
Registration Endpoint URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: scopes_supported
o 메타데이터 설명: 이 인가 서버가 지원하는 OAuth 2.0 "scope"
값 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: response_types_supported
o 메타데이터 설명: 이 인가 서버가 지원하는 OAuth 2.0
"response_type" 값 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: response_modes_supported
o 메타데이터 설명: 이 인가 서버가 지원하는 OAuth 2.0
"response_mode" 값 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
Jones, et al. 표준 트랙 [Page 16]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
o 메타데이터 이름: grant_types_supported
o 메타데이터 설명: 이 인가 서버가 지원하는 OAuth 2.0 grant type
값 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: token_endpoint_auth_methods_supported
o 메타데이터 설명: 이 token endpoint가 지원하는 client
authentication method 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: token_endpoint_auth_signing_alg_values_supported
o 메타데이터 설명: token endpoint에서 클라이언트를 인증하는 데
사용되는 JWT의 서명에 대해 token endpoint가 지원하는 JWS
서명 알고리즘 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: service_documentation
o 메타데이터 설명: 개발자가 인가 서버를 사용할 때 알고 싶어
하거나 알아야 할 수 있는 사람이 읽을 수 있는 정보를 포함하는
페이지의 URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: ui_locales_supported
o 메타데이터 설명: 사용자 인터페이스에 대해 지원되는 언어와
문자 체계로, BCP 47의 language tag 값 JSON 배열로 표현됨
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: op_policy_uri
o 메타데이터 설명: 인가 서버가 제공하는 데이터를 클라이언트가
어떻게 사용할 수 있는지에 대한 인가 서버의 요구사항을 읽도록
인가 서버가 클라이언트를 등록하는 사람에게 제공하는 URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: op_tos_uri
o 메타데이터 설명: 인가 서버의 서비스 약관을 읽도록 인가 서버가
클라이언트를 등록하는 사람에게 제공하는 URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
Jones, et al. 표준 트랙 [Page 17]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
o 메타데이터 이름: revocation_endpoint
o 메타데이터 설명: 인가 서버의 OAuth 2.0 revocation endpoint URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: revocation_endpoint_auth_methods_supported
o 메타데이터 설명: 이 revocation endpoint가 지원하는 client
authentication method 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름:
revocation_endpoint_auth_signing_alg_values_supported
o 메타데이터 설명: revocation endpoint에서 클라이언트를 인증하는
데 사용되는 JWT의 서명에 대해 revocation endpoint가 지원하는
JWS 서명 알고리즘 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: introspection_endpoint
o 메타데이터 설명: 인가 서버의 OAuth 2.0 introspection endpoint URL
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: introspection_endpoint_auth_methods_supported
o 메타데이터 설명: 이 introspection endpoint가 지원하는 client
authentication method 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름:
introspection_endpoint_auth_signing_alg_values_supported
o 메타데이터 설명: introspection endpoint에서 클라이언트를 인증하는
데 사용되는 JWT의 서명에 대해 introspection endpoint가 지원하는
JWS 서명 알고리즘 목록을 포함하는 JSON 배열
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
o 메타데이터 이름: code_challenge_methods_supported
o 메타데이터 설명: 이 인가 서버가 지원하는 PKCE code challenge
method
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2
Jones, et al. 표준 트랙 [Page 18]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
o 메타데이터 이름: signed_metadata
o 메타데이터 설명: 인가 서버에 대한 메타데이터 값을 클레임으로
포함하는 서명된 JWT
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 2.1
7.2. 갱신된 등록 지침
이 명세는 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]에
속한 다음 두 IANA 레지스트리의 Designated Expert를 위한 지침에
추가된다.
o OAuth Access Token Types
o OAuth Token Endpoint Authentication Methods
IANA는 이러한 레지스트리의 Reference 섹션에 이 명세에 대한 링크를
추가했다.
이러한 레지스트리에 대해, Designated Expert는 한 레지스트리에
이미 존재하는 값에 대한 다른 레지스트리의 등록 요청을 거부해야
한다. 이는 "introspection_endpoint_auth_methods_supported"
파라미터가 어느 레지스트리의 값이든 사용할 수 있도록 허용하기
때문에 필요하다. 그렇게 하면 두 레지스트리의 값이 계속 상호
배타적이므로 모호성이 발생하지 않는다.
7.3. Well-Known URI 레지스트리
이 명세는 Section 3에서 정의한 well-known URI를 RFC 5785
[RFC5785]가 수립한 IANA "Well-Known URIs" 레지스트리
[IANA.well-known]에 등록한다.
7.3.1. 레지스트리 내용
o URI suffix: oauth-authorization-server
o 변경 관리자: IESG
o 명세 문서: RFC 8414의 Section 3
o 관련 정보: (없음)
Jones, et al. 표준 트랙 [Page 19]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
8. 참고문헌
8.1. 규범적 참고문헌
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Transport Layer Security(TLS) 및 Datagram Transport
Layer Security(DTLS)의 안전한 사용을 위한 권고사항",
BCP 195, RFC 7525, 2015년 5월,
<http://www.rfc-editor.org/info/bcp195>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<https://www.iana.org/assignments/oauth-parameters>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, 2015년 5월,
<https://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015년 5월,
<https://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015년
5월, <https://www.rfc-editor.org/info/rfc7515>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, 2015년 5월,
<https://www.rfc-editor.org/info/rfc7519>.
[OAuth.Post]
Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
Mode", 2015년 4월, <http://openid.net/specs/
oauth-v2-form-post-response-mode-1_0.html>.
[OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding
Practices", 2014년 2월, <http://openid.net/specs/
oauth-v2-multiple-response-types-1_0.html>.
[RFC2119] Bradner, S., "요구사항 수준을 나타내기 위해 RFC에서
사용하는 핵심 단어", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<https://www.rfc-editor.org/info/rfc2119>.
Jones, et al. 표준 트랙 [Page 20]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
[RFC5246] Dierks, T. and E. Rescorla, "Transport Layer Security
(TLS) 프로토콜 버전 1.2", RFC 5246,
DOI 10.17487/RFC5246, 2008년 8월,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "언어 식별을 위한
태그", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
2009년 9월, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Well-Known Uniform
Resource Identifier(URI) 정의", RFC 5785,
DOI 10.17487/RFC5785, 2010년 4월,
<https://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Transport Layer
Security(TLS)의 맥락에서 X.509(PKIX) 인증서를 사용하는
인터넷 공개 키 기반 구조 내 도메인 기반 애플리케이션
서비스 식별자의 표현 및 검증", RFC 6125,
DOI 10.17487/RFC6125, 2011년 3월,
<https://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "OAuth 2.0 인가 프레임워크",
RFC 6749, DOI 10.17487/RFC6749, 2012년 10월,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 토큰 폐기", RFC 7009, DOI 10.17487/RFC7009,
2013년 8월, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, 2013년
9월, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, 2015년 7월,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "OAuth
공개 클라이언트를 위한 Proof Key for Code Exchange",
RFC 7636, DOI 10.17487/RFC7636, 2015년 9월,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 토큰 인트로스펙션",
RFC 7662, DOI 10.17487/RFC7662, 2015년 10월,
<https://www.rfc-editor.org/info/rfc7662>.
Jones, et al. 표준 트랙 [Page 21]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "RFC의 IANA 고려사항
섹션 작성 지침", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, 2017년 6월,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "RFC 2119 핵심 단어의 대문자와 소문자
모호성", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "JavaScript Object Notation(JSON) 데이터
교환 형식", STD 90, RFC 8259,
DOI 10.17487/RFC8259, 2017년 12월,
<https://www.rfc-editor.org/info/rfc8259>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
[USA15] Davis, M., Ed. and K. Whistler, Ed., "Unicode
Normalization Forms", Unicode Standard Annex #15, 2018년
5월, <http://www.unicode.org/reports/tr15/>.
8.2. 정보성 참고문헌
[IANA.well-known]
IANA, "Well-Known URIs",
<https://www.iana.org/assignments/well-known-uris>.
[MIX-UP] Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up
Mitigation", 진행 중인 작업, draft-ietf-oauth-mix-up-
mitigation-01, 2016년 7월.
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", 2014년 11월,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[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>.
Jones, et al. 표준 트랙 [Page 22]
RFC 8414 OAuth 2.0 인가 서버 메타데이터 2018년 6월
감사의 말
이 명세는 OpenID Foundation의 OpenID Connect 워킹 그룹이 만든
OpenID Connect Discovery 1.0 명세를 기반으로 한다. 이 명세는 OAuth
인가 서버 메타데이터를 게시하기 위해 OpenID Connect Discovery가
정의한 메타데이터 형식의 사실상 사용을 표준화한다.
저자들은 이 명세를 검토해 준 다음 사람들에게 감사한다: Shwetha
Bhandari, Ben Campbell, Brian Campbell, Brian Carpenter, William
Denniss, Vladimir Dzhuvinov, Donald Eastlake, Samuel Erdtman, George
Fletcher, Dick Hardt, Phil Hunt, Alexey Melnikov, Tony Nadalin, Mark
Nottingham, Eric Rescorla, Justin Richer, Adam Roach, Hannes
Tschofenig, and Hans Zandbelt.
저자 주소
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
URI: http://self-issued.info/
Nat Sakimura
Nomura Research Institute, Ltd.
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
John Bradley
Yubico
Email: RFC8414@ve7jtb.com
URI: http://www.thread-safe.com/
Jones, et al. 표준 트랙 [Page 23]