Internet Engineering Task Force (IETF) D. Hardt, Ed. 논평 요청: 6749 Microsoft 폐기: 5849 2012년 10월 분류: 표준 트랙 ISSN: 2070-1721 OAuth 2.0 인가 프레임워크 초록 OAuth 2.0 인가 프레임워크는 서드파티 애플리케이션이 HTTP 서비스에 대한 제한된 접근 권한을 얻을 수 있게 한다. 이는 리소스 소유자를 대신하여 리소스 소유자와 HTTP 서비스 사이의 승인 상호작용을 조율하거나, 서드파티 애플리케이션이 자기 자신을 대신하여 접근 권한을 얻도록 허용하는 방식으로 이루어진다. 이 명세는 RFC 5849에 설명된 OAuth 1.0 프로토콜을 대체하고 폐기한다. 이 메모의 상태 이 문서는 인터넷 표준 트랙 문서이다. 이 문서는 Internet Engineering Task Force (IETF)의 산물이다. 이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며 Internet Engineering Steering Group (IESG)에 의해 출판 승인을 받았다. 인터넷 표준에 대한 추가 정보는 RFC 5741의 Section 2에서 확인할 수 있다. 이 문서의 현재 상태, 정오표, 그리고 이에 대한 피드백 제공 방법에 관한 정보는 다음에서 얻을 수 있다. http://www.rfc-editor.org/info/rfc6749. Copyright Notice Copyright (c) 2012 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. Hardt 표준 트랙 [Page 1]
RFC 6749 OAuth 2.0 2012년 10월 목차 1. 소개 ..........................................................4 1.1. 역할 ......................................................6 1.2. 프로토콜 흐름 .............................................7 1.3. 인가 부여 .................................................8 1.3.1. 인가 코드 ........................................8 1.3.2. 암시적 ...........................................8 1.3.3. 리소스 소유자 비밀번호 자격 증명 .................9 1.3.4. 클라이언트 자격 증명 .............................9 1.4. 접근 토큰 ................................................10 1.5. 갱신 토큰 ................................................10 1.6. TLS 버전 .................................................12 1.7. HTTP 리디렉션 ............................................12 1.8. 상호 운용성 ..............................................12 1.9. 표기 관례 ................................................13 2. 클라이언트 등록 ...............................................13 2.1. 클라이언트 유형 ..........................................14 2.2. 클라이언트 식별자 ........................................15 2.3. 클라이언트 인증 ..........................................16 2.3.1. 클라이언트 비밀번호 ..............................16 2.3.2. 기타 인증 방법 ...................................17 2.4. 등록되지 않은 클라이언트 .................................17 3. 프로토콜 엔드포인트 ..........................................18 3.1. 인가 엔드포인트 ..........................................18 3.1.1. 응답 유형 ........................................19 3.1.2. 리디렉션 엔드포인트 .............................19 3.2. 토큰 엔드포인트 ..........................................21 3.2.1. 클라이언트 인증 ..................................22 3.3. 접근 토큰 범위 ...........................................23 4. 인가 획득 ....................................................23 4.1. 인가 코드 부여 ...........................................24 4.1.1. 인가 요청 ........................................25 4.1.2. 인가 응답 ........................................26 4.1.3. 접근 토큰 요청 ...................................29 4.1.4. 접근 토큰 응답 ...................................30 4.2. 암시적 부여 ..............................................31 4.2.1. 인가 요청 ........................................33 4.2.2. 접근 토큰 응답 ...................................35 4.3. 리소스 소유자 비밀번호 자격 증명 부여 ....................37 4.3.1. 인가 요청 및 응답 .................................39 4.3.2. 접근 토큰 요청 ...................................39 4.3.3. 접근 토큰 응답 ...................................40 4.4. 클라이언트 자격 증명 부여 .................................40 4.4.1. 인가 요청 및 응답 .................................41 4.4.2. 접근 토큰 요청 ...................................41 4.4.3. 접근 토큰 응답 ...................................42 4.5. 확장 부여 ................................................42 Hardt 표준 트랙 [Page 2]
RFC 6749 OAuth 2.0 2012년 10월 5. 접근 토큰 발급 ................................................43 5.1. 성공 응답 ................................................43 5.2. 오류 응답 ................................................45 6. 접근 토큰 갱신 ................................................47 7. 보호된 리소스 접근 ............................................48 7.1. 접근 토큰 유형 ............................................49 7.2. 오류 응답 ................................................49 8. 확장성 ........................................................50 8.1. 접근 토큰 유형 정의 .......................................50 8.2. 새 엔드포인트 매개변수 정의 ...............................50 8.3. 새 인가 부여 유형 정의 ....................................51 8.4. 새 인가 엔드포인트 응답 유형 정의 ........................51 8.5. 추가 오류 코드 정의 .......................................51 9. 네이티브 애플리케이션 .........................................52 10. 보안 고려사항 ...............................................53 10.1. 클라이언트 인증 ........................................53 10.2. 클라이언트 사칭 ........................................54 10.3. 접근 토큰 ..............................................55 10.4. 갱신 토큰 ..............................................55 10.5. 인가 코드 ..............................................56 10.6. 인가 코드 리디렉션 URI 조작 ............................56 10.7. 리소스 소유자 비밀번호 자격 증명 .......................57 10.8. 요청 기밀성 ............................................58 10.9. 엔드포인트 진정성 보장 .................................58 10.10. 자격 증명 추측 공격 ...................................58 10.11. 피싱 공격 .............................................58 10.12. 사이트 간 요청 위조 ...................................59 10.13. 클릭재킹 ..............................................60 10.14. 코드 주입 및 입력 검증 .................................60 10.15. 오픈 리디렉터 .........................................60 10.16. 암시적 흐름에서 리소스 소유자를 사칭하기 위한 접근 토큰의 오용 .......................................61 11. IANA 고려사항 ...............................................62 11.1. OAuth 접근 토큰 유형 레지스트리 ........................62 11.1.1. 등록 템플릿 .....................................62 11.2. OAuth 매개변수 레지스트리 ..............................63 11.2.1. 등록 템플릿 .....................................63 11.2.2. 초기 레지스트리 내용 ............................64 11.3. OAuth 인가 엔드포인트 응답 유형 레지스트리 .............66 11.3.1. 등록 템플릿 .....................................66 11.3.2. 초기 레지스트리 내용 ............................67 11.4. OAuth 확장 오류 레지스트리 .............................67 11.4.1. 등록 템플릿 .....................................68 12. 참고문헌 ....................................................68 12.1. 규범적 참고문헌 ........................................68 12.2. 정보성 참고문헌 ........................................70 Hardt 표준 트랙 [Page 3]
RFC 6749 OAuth 2.0 2012년 10월 부록 A. Augmented Backus-Naur Form (ABNF) 구문 .................71 A.1. "client_id" 구문 .......................................71 A.2. "client_secret" 구문 ...................................71 A.3. "response_type" 구문 ...................................71 A.4. "scope" 구문 ...........................................72 A.5. "state" 구문 ...........................................72 A.6. "redirect_uri" 구문 ....................................72 A.7. "error" 구문 ...........................................72 A.8. "error_description" 구문 ...............................72 A.9. "error_uri" 구문 .......................................72 A.10. "grant_type" 구문 ......................................73 A.11. "code" 구문 ............................................73 A.12. "access_token" 구문 ....................................73 A.13. "token_type" 구문 ......................................73 A.14. "expires_in" 구문 ......................................73 A.15. "username" 구문 ........................................73 A.16. "password" 구문 ........................................73 A.17. "refresh_token" 구문 ...................................74 A.18. 엔드포인트 매개변수 구문 ...............................74 부록 B. application/x-www-form-urlencoded 미디어 유형의 사용 ...74 부록 C. 감사의 말 .............................................75 1. 소개 전통적인 클라이언트-서버 인증 모델에서 클라이언트는 리소스 소유자의 자격 증명을 사용하여 서버에 인증함으로써 서버의 접근 제한 리소스(보호된 리소스)를 요청한다. 서드파티 애플리케이션에 제한된 리소스에 대한 접근을 제공하기 위해 리소스 소유자는 자신의 자격 증명을 서드파티와 공유한다. 이는 여러 문제와 제한을 만든다. o 서드파티 애플리케이션은 향후 사용을 위해 리소스 소유자의 자격 증명, 일반적으로 평문 비밀번호를 저장해야 한다. o 서버는 비밀번호에 내재된 보안 취약점에도 불구하고 비밀번호 인증을 지원해야 한다. o 서드파티 애플리케이션은 리소스 소유자의 보호된 리소스에 지나치게 넓은 접근 권한을 얻게 되며, 리소스 소유자는 기간이나 제한된 리소스 하위 집합에 대한 접근을 제한할 수단을 갖지 못한다. o 리소스 소유자는 모든 서드파티에 대한 접근을 취소하지 않고는 개별 서드파티에 대한 접근을 취소할 수 없으며, 이를 위해 서드파티의 비밀번호를 변경해야 한다. Hardt 표준 트랙 [Page 4]
RFC 6749 OAuth 2.0 2012년 10월 o 어떤 서드파티 애플리케이션이든 침해되면 최종 사용자의 비밀번호와 그 비밀번호로 보호되는 모든 데이터가 침해된다. OAuth는 인가 계층을 도입하고 클라이언트의 역할을 리소스 소유자의 역할과 분리함으로써 이러한 문제를 해결한다. OAuth에서 클라이언트는 리소스 소유자가 제어하고 리소스 서버가 호스팅하는 리소스에 대한 접근을 요청하며, 리소스 소유자의 자격 증명과는 다른 자격 증명 집합을 발급받는다. 보호된 리소스에 접근하기 위해 리소스 소유자의 자격 증명을 사용하는 대신, 클라이언트는 특정 범위, 수명, 기타 접근 속성을 나타내는 문자열인 접근 토큰을 얻는다. 접근 토큰은 리소스 소유자의 승인에 따라 인가 서버가 서드파티 클라이언트에 발급한다. 클라이언트는 접근 토큰을 사용하여 리소스 서버가 호스팅하는 보호된 리소스에 접근한다. 예를 들어 최종 사용자(리소스 소유자)는 사진 공유 서비스(리소스 서버)에 저장된 자신의 보호된 사진에 대해 인쇄 서비스(클라이언트)에 접근 권한을 부여할 수 있으며, 이때 사용자 이름과 비밀번호를 인쇄 서비스와 공유하지 않는다. 대신, 사용자는 사진 공유 서비스가 신뢰하는 서버(인가 서버)에 직접 인증하고, 이 서버는 인쇄 서비스에 위임 전용 자격 증명(접근 토큰)을 발급한다. 이 명세는 HTTP([RFC2616])와 함께 사용하도록 설계되었다. HTTP 이외의 프로토콜에서 OAuth를 사용하는 것은 범위를 벗어난다. 정보성 문서로 출판된 OAuth 1.0 프로토콜([RFC5849])은 소규모 임시 커뮤니티 노력의 결과였다. 이 표준 트랙 명세는 OAuth 1.0 배포 경험과 더 넓은 IETF 커뮤니티에서 수집한 추가 사용 사례 및 확장성 요구사항을 바탕으로 한다. OAuth 2.0 프로토콜은 OAuth 1.0과 하위 호환되지 않는다. 두 버전은 네트워크에서 공존할 수 있으며, 구현은 둘 다 지원하도록 선택할 수 있다. 그러나 이 명세의 의도는 새 구현이 이 문서에 명시된 OAuth 2.0을 지원하고, OAuth 1.0은 기존 배포를 지원하는 데만 사용되도록 하는 것이다. OAuth 2.0 프로토콜은 OAuth 1.0 프로토콜과 구현 세부사항을 거의 공유하지 않는다. OAuth 1.0에 익숙한 구현자는 이 문서의 구조와 세부사항에 대해 어떠한 가정도 하지 않고 접근해야 한다. Hardt 표준 트랙 [Page 5]
RFC 6749 OAuth 2.0 2012년 10월 1.1. 역할 OAuth는 네 가지 역할을 정의한다. 리소스 소유자 보호된 리소스에 대한 접근을 부여할 수 있는 엔터티이다. 리소스 소유자가 사람인 경우 최종 사용자라고 부른다. 리소스 서버 보호된 리소스를 호스팅하는 서버로서, 접근 토큰을 사용한 보호된 리소스 요청을 수락하고 응답할 수 있다. 클라이언트 리소스 소유자를 대신하여, 그리고 그 인가에 따라 보호된 리소스 요청을 수행하는 애플리케이션이다. "client"라는 용어는 특정 구현 특성(예: 애플리케이션이 서버, 데스크톱, 기타 장치에서 실행되는지 여부)을 의미하지 않는다. 인가 서버 리소스 소유자를 성공적으로 인증하고 인가를 얻은 후 클라이언트에 접근 토큰을 발급하는 서버이다. 인가 서버와 리소스 서버 간의 상호작용은 이 명세의 범위를 벗어난다. 인가 서버는 리소스 서버와 동일한 서버일 수도 있고 별도의 엔터티일 수도 있다. 단일 인가 서버는 여러 리소스 서버가 수락하는 접근 토큰을 발급할 수 있다. Hardt 표준 트랙 [Page 6]
RFC 6749 OAuth 2.0 2012년 10월 1.2. 프로토콜 흐름 +--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+ 그림 1: 추상 프로토콜 흐름 그림 1에 표시된 추상 OAuth 2.0 흐름은 네 역할 간의 상호작용을 설명하며 다음 단계를 포함한다. (A) 클라이언트는 리소스 소유자에게 인가를 요청한다. 인가 요청은 리소스 소유자에게 직접(그림과 같이) 할 수도 있고, 바람직하게는 인가 서버를 중개자로 통해 간접적으로 할 수도 있다. (B) 클라이언트는 리소스 소유자의 인가를 나타내는 자격 증명인 인가 부여를 받는다. 이는 이 명세에 정의된 네 가지 부여 유형 중 하나 또는 확장 부여 유형으로 표현된다. 인가 부여 유형은 클라이언트가 인가를 요청하는 데 사용한 방법과 인가 서버가 지원하는 유형에 따라 달라진다. (C) 클라이언트는 인가 서버에 인증하고 인가 부여를 제시하여 접근 토큰을 요청한다. (D) 인가 서버는 클라이언트를 인증하고 인가 부여를 검증하며, 유효하면 접근 토큰을 발급한다. Hardt 표준 트랙 [Page 7]
RFC 6749 OAuth 2.0 2012년 10월 (E) 클라이언트는 접근 토큰을 제시하여 인증하고 리소스 서버에 보호된 리소스를 요청한다. (F) 리소스 서버는 접근 토큰을 검증하고, 유효하면 요청을 처리한다. 클라이언트가 리소스 소유자로부터 인가 부여를 얻는 선호 방법(단계 (A)와 (B)에 묘사됨)은 인가 서버를 중개자로 사용하는 것이며, 이는 Section 4.1의 그림 3에 표시되어 있다. 1.3. 인가 부여 인가 부여는 리소스 소유자의 인가(그 보호된 리소스에 접근하기 위한)를 나타내는 자격 증명이며, 클라이언트가 접근 토큰을 얻는 데 사용한다. 이 명세는 네 가지 부여 유형, 즉 인가 코드, 암시적, 리소스 소유자 비밀번호 자격 증명, 클라이언트 자격 증명을 정의하며, 추가 유형을 정의하기 위한 확장성 메커니즘도 함께 정의한다. 1.3.1. 인가 코드 인가 코드는 클라이언트와 리소스 소유자 사이의 중개자로 인가 서버를 사용하여 얻는다. 클라이언트는 리소스 소유자에게 직접 인가를 요청하는 대신, 리소스 소유자를 인가 서버로 안내한다([RFC2616]에 정의된 사용자 에이전트를 통해). 그러면 인가 서버는 인가 코드와 함께 리소스 소유자를 다시 클라이언트로 안내한다. 인가 서버는 인가 코드와 함께 리소스 소유자를 클라이언트로 다시 안내하기 전에 리소스 소유자를 인증하고 인가를 얻는다. 리소스 소유자는 인가 서버에만 인증하므로, 리소스 소유자의 자격 증명은 클라이언트와 절대 공유되지 않는다. 인가 코드는 클라이언트를 인증할 수 있는 능력과, 접근 토큰을 리소스 소유자의 사용자 에이전트를 거치지 않고 클라이언트에 직접 전달함으로써 리소스 소유자를 포함한 다른 이에게 노출될 가능성을 줄이는 등 몇 가지 중요한 보안 이점을 제공한다. 1.3.2. 암시적 암시적 부여는 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현된 클라이언트에 최적화된 단순화된 인가 코드 흐름이다. 암시적 흐름에서는 클라이언트에 인가 코드를 발급하는 대신 접근 토큰을 직접 발급한다. Hardt 표준 트랙 [Page 8]
RFC 6749 OAuth 2.0 2012년 10월 (리소스 소유자 인가의 결과로). 부여 유형은 암시적이다. 왜냐하면 인가 코드와 같은 중간 자격 증명이 발급되지 않으며 이후 접근 토큰을 얻기 위해 사용되지도 않기 때문이다. 암시적 부여 흐름 중 접근 토큰을 발급할 때, 인가 서버는 클라이언트를 인증하지 않는다. 경우에 따라, 접근 토큰을 클라이언트에 전달하는 데 사용되는 리디렉션 URI를 통해 클라이언트 신원을 확인할 수 있다. 접근 토큰은 리소스 소유자 또는 리소스 소유자의 사용자 에이전트에 접근할 수 있는 다른 애플리케이션에 노출될 수 있다. 암시적 부여는 접근 토큰을 얻기 위해 필요한 왕복 횟수를 줄이기 때문에, 일부 클라이언트(예: 브라우저 내 애플리케이션 으로 구현된 클라이언트)의 응답성과 효율성을 향상시킨다. 그러나 이러한 편의성은 특히 인가 코드 부여 유형을 사용할 수 있을 때, 10.3 및 10.16절에 설명된 것과 같은 암시적 부여 사용의 보안 영향을 고려하여 평가해야 한다. 1.3.3. 리소스 소유자 비밀번호 자격 증명 리소스 소유자 비밀번호 자격 증명(즉, 사용자 이름과 비밀번호)은 접근 토큰을 얻기 위한 인가 부여로 직접 사용할 수 있다. 이 자격 증명은 리소스 소유자와 클라이언트 사이에 높은 수준의 신뢰가 있을 때(예: 클라이언트가 장치 운영 체제의 일부이거나 높은 권한을 가진 애플리케이션인 경우), 그리고 다른 인가 부여 유형(예: 인가 코드)을 사용할 수 없을 때에만 사용해야 한다. 이 부여 유형은 리소스 소유자 자격 증명에 대한 클라이언트의 직접 접근을 요구하지만, 리소스 소유자 자격 증명은 단일 요청에 사용되고 접근 토큰으로 교환된다. 이 부여 유형은 자격 증명을 장기 수명의 접근 토큰이나 갱신 토큰으로 교환함으로써, 클라이언트가 향후 사용을 위해 리소스 소유자 자격 증명을 저장할 필요를 없앨 수 있다. 1.3.4. 클라이언트 자격 증명 클라이언트 자격 증명(또는 다른 형태의 클라이언트 인증)은 인가 범위가 클라이언트가 제어하는 보호된 리소스 또는 인가 서버와 사전에 조율된 보호된 리소스로 제한될 때 인가 부여로 사용될 수 있다. 클라이언트 자격 증명은 일반적으로 클라이언트가 자기 자신을 대신하여 동작할 때 (클라이언트가 리소스 소유자이기도 한 경우), 또는 인가 서버와 사전에 조율된 인가에 근거하여 보호된 리소스에 대한 접근을 요청할 때 인가 부여로 사용된다. Hardt 표준 트랙 [Page 9]
RFC 6749 OAuth 2.0 2012년 10월 1.4. 접근 토큰 접근 토큰은 보호된 리소스에 접근하는 데 사용되는 자격 증명이다. 접근 토큰은 클라이언트에 발급된 인가를 나타내는 문자열이다. 이 문자열은 일반적으로 클라이언트에 불투명하다. 토큰은 리소스 소유자가 부여하고 리소스 서버와 인가 서버가 집행하는 특정 접근 범위와 기간을 나타낸다. 토큰은 인가 정보를 검색하는 데 사용되는 식별자를 나타낼 수도 있고, 검증 가능한 방식으로 인가 정보를 자체 포함할 수도 있다(즉, 일부 데이터와 서명으로 구성된 토큰 문자열). 클라이언트가 토큰을 사용하기 위해 이 명세의 범위를 벗어난 추가 인증 자격 증명이 필요할 수 있다. 접근 토큰은 추상화 계층을 제공하여, 서로 다른 인가 구성 요소(예: 사용자 이름과 비밀번호)를 리소스 서버가 이해하는 단일 토큰으로 대체한다. 이러한 추상화는 접근 토큰을 얻는 데 사용된 인가 부여보다 더 제한적인 접근 토큰을 발급할 수 있게 하며, 리소스 서버가 광범위한 인증 방법을 이해해야 할 필요를 없앤다. 접근 토큰은 리소스 서버의 보안 요구사항에 따라 다양한 형식, 구조, 활용 방법(예: 암호학적 속성)을 가질 수 있다. 접근 토큰 속성과 보호된 리소스에 접근하는 데 사용되는 방법은 이 명세의 범위를 벗어나며, [RFC6750]과 같은 동반 명세에서 정의된다. 1.5. 갱신 토큰 갱신 토큰은 접근 토큰을 얻는 데 사용되는 자격 증명이다. 갱신 토큰은 인가 서버가 클라이언트에 발급하며, 현재 접근 토큰이 무효화되거나 만료될 때 새 접근 토큰을 얻거나, 동일하거나 더 좁은 범위를 가진 추가 접근 토큰을 얻는 데 사용된다(접근 토큰은 리소스 소유자가 인가한 것보다 더 짧은 수명과 더 적은 권한을 가질 수 있다). 갱신 토큰 발급은 인가 서버의 재량에 따른 선택 사항이다. 인가 서버가 갱신 토큰을 발급하는 경우, 접근 토큰을 발급할 때 함께 포함된다 (즉, 그림 1의 단계 (D)). 갱신 토큰은 리소스 소유자가 클라이언트에 부여한 인가를 나타내는 문자열이다. 이 문자열은 일반적으로 클라이언트에 불투명하다. 토큰은 인가 정보를 검색하는 데 사용되는 Hardt 표준 트랙 [Page 10]
RFC 6749 OAuth 2.0 2012년 10월 식별자를 나타낸다. 접근 토큰과 달리 갱신 토큰은 인가 서버에서만 사용하도록 의도되며, 리소스 서버에는 절대 전송되지 않는다. +--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+ 그림 2: 만료된 접근 토큰 갱신 그림 2에 표시된 흐름은 다음 단계를 포함한다. (A) 클라이언트는 인가 서버에 인증하고 인가 부여를 제시하여 접근 토큰을 요청한다. (B) 인가 서버는 클라이언트를 인증하고 인가 부여를 검증하며, 유효하면 접근 토큰과 갱신 토큰을 발급한다. (C) 클라이언트는 접근 토큰을 제시하여 리소스 서버에 보호된 리소스 요청을 수행한다. (D) 리소스 서버는 접근 토큰을 검증하고, 유효하면 요청을 처리한다. (E) 단계 (C)와 (D)는 접근 토큰이 만료될 때까지 반복된다. 클라이언트가 접근 토큰이 만료되었음을 알고 있으면 단계 (G)로 건너뛰고, 그렇지 않으면 또 다른 보호된 리소스 요청을 수행한다. (F) 접근 토큰이 유효하지 않으므로, 리소스 서버는 유효하지 않은 토큰 오류를 반환한다. Hardt 표준 트랙 [Page 11]
RFC 6749 OAuth 2.0 2012년 10월 (G) 클라이언트는 인가 서버에 인증하고 갱신 토큰을 제시하여 새 접근 토큰을 요청한다. 클라이언트 인증 요구사항은 클라이언트 유형과 인가 서버 정책에 기반한다. (H) 인가 서버는 클라이언트를 인증하고 갱신 토큰을 검증하며, 유효하면 새 접근 토큰(그리고 선택적으로 새 갱신 토큰)을 발급한다. 단계 (C), (D), (E), (F)는 Section 7에 설명된 것처럼 이 명세의 범위를 벗어난다. 1.6. TLS 버전 이 명세에서 Transport Layer Security (TLS)가 사용될 때마다, 적절한 TLS 버전(또는 버전들)은 광범위한 배포와 알려진 보안 취약점에 따라 시간이 지남에 따라 달라진다. 이 글을 쓰는 시점에 TLS 버전 1.2 [RFC5246]가 가장 최신 버전이지만, 배포 기반이 매우 제한적이며 구현에 쉽게 사용할 수 없을 수 있다. TLS 버전 1.0 [RFC2246]은 가장 널리 배포된 버전이며 가장 넓은 상호 운용성을 제공한다. 구현은 보안 요구사항을 충족하는 추가 전송 계층 보안 메커니즘도 지원할 수 있다(MAY). 1.7. HTTP 리디렉션 이 명세는 HTTP 리디렉션을 광범위하게 사용하며, 이 경우 클라이언트 또는 인가 서버는 리소스 소유자의 사용자 에이전트를 다른 목적지로 안내한다. 이 명세의 예에서는 HTTP 302 상태 코드 사용을 보여주지만, 이 리디렉션을 달성하기 위해 사용자 에이전트를 통해 사용할 수 있는 다른 어떤 방법도 허용되며 구현 세부사항으로 간주된다. 1.8. 상호 운용성 OAuth 2.0은 잘 정의된 보안 속성을 가진 풍부한 인가 프레임워크를 제공한다. 그러나 선택적 구성 요소가 많은 풍부하고 매우 확장 가능한 프레임워크로서, 이 명세만으로는 광범위한 비상호운용 구현을 낳을 가능성이 있다. 또한 이 명세는 일부 필수 구성 요소(예: 클라이언트 등록, 인가 서버 기능, 엔드포인트 발견)를 부분적으로 또는 완전히 정의하지 않은 채 남겨둔다. 이러한 구성 요소가 없으면, Hardt 표준 트랙 [Page 12]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트는 상호 운용하기 위해 특정 인가 서버와 리소스 서버에 대해 수동으로, 그리고 구체적으로 구성되어야 한다. 이 프레임워크는 향후 작업이 웹 규모의 완전한 상호 운용성을 달성하는 데 필요한 규범적 프로파일과 확장을 정의할 것이라는 명확한 기대를 가지고 설계되었다. 1.9. 표기 관례 이 명세의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"은 [RFC2119]에 설명된 대로 해석한다. 이 명세는 [RFC5234]의 Augmented Backus-Naur Form (ABNF) 표기법을 사용한다. 또한 "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986]에서 URI-reference 규칙을 포함한다. 특정 보안 관련 용어는 [RFC4949]에 정의된 의미로 이해한다. 이러한 용어에는 "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", "verify"가 포함되지만 이에 한정되지 않는다. 달리 명시되지 않는 한, 모든 프로토콜 매개변수 이름과 값은 대소문자를 구분한다. 2. 클라이언트 등록 프로토콜을 시작하기 전에, 클라이언트는 인가 서버에 등록한다. 클라이언트가 인가 서버에 등록하는 수단은 이 명세의 범위를 벗어나지만, 일반적으로 HTML 등록 양식을 통한 최종 사용자 상호작용을 포함한다. 클라이언트 등록은 클라이언트와 인가 서버 간의 직접 상호작용을 요구하지 않는다. 인가 서버가 지원하는 경우, 등록은 신뢰를 설정하고 필요한 클라이언트 속성(예: 리디렉션 URI, 클라이언트 유형)을 얻기 위한 다른 수단에 의존할 수 있다. 예를 들어, 등록은 자체 발급 또는 서드파티 발급 assertion을 사용하여 수행되거나, 인가 서버가 신뢰된 채널을 사용하여 클라이언트 발견을 수행함으로써 이루어질 수 있다. Hardt 표준 트랙 [Page 13]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트를 등록할 때, 클라이언트 개발자는 다음을 해야 한다 (SHALL). o Section 2.1에 설명된 대로 클라이언트 유형을 지정한다. o Section 3.1.2에 설명된 대로 클라이언트 리디렉션 URI를 제공한다. 그리고 o 인가 서버가 요구하는 기타 정보(예: 애플리케이션 이름, 웹 사이트, 설명, 로고 이미지, 법적 조건 수락)를 포함한다. 2.1. 클라이언트 유형 OAuth는 인가 서버에 안전하게 인증할 수 있는 능력(즉, 클라이언트 자격 증명의 기밀성을 유지할 수 있는 능력)을 기준으로 두 가지 클라이언트 유형을 정의한다. confidential 자신의 자격 증명의 기밀성을 유지할 수 있는 클라이언트 (예: 클라이언트 자격 증명에 대한 접근이 제한된 보안 서버에 구현된 클라이언트), 또는 다른 수단을 사용하여 안전한 클라이언트 인증을 수행할 수 있는 클라이언트이다. public 자신의 자격 증명의 기밀성을 유지할 수 없는 클라이언트 (예: 설치된 네이티브 애플리케이션 또는 웹 브라우저 기반 애플리케이션처럼 리소스 소유자가 사용하는 장치에서 실행되는 클라이언트)이며, 다른 어떤 수단으로도 안전한 클라이언트 인증을 수행할 수 없는 클라이언트이다. 클라이언트 유형 지정은 인가 서버의 안전한 인증 정의와 클라이언트 자격 증명의 허용 가능한 노출 수준에 기반한다. 인가 서버는 클라이언트 유형에 대해 가정해서는 안 된다 (SHOULD NOT). 클라이언트는 각각 다른 클라이언트 유형과 보안 컨텍스트를 가진 분산된 구성 요소 집합으로 구현될 수 있다(예: 기밀 서버 기반 구성 요소와 공개 브라우저 기반 구성 요소를 모두 가진 분산 클라이언트). 인가 서버가 이러한 클라이언트를 지원하지 않거나 등록에 관한 지침을 제공하지 않는 경우, 클라이언트는 각 구성 요소를 별도의 클라이언트로 등록해야 한다(SHOULD). Hardt 표준 트랙 [Page 14]
RFC 6749 OAuth 2.0 2012년 10월 이 명세는 다음 클라이언트 프로파일을 중심으로 설계되었다. web application 웹 애플리케이션은 웹 서버에서 실행되는 confidential 클라이언트이다. 리소스 소유자는 리소스 소유자가 사용하는 장치의 사용자 에이전트에서 렌더링된 HTML 사용자 인터페이스를 통해 클라이언트에 접근한다. 클라이언트 자격 증명과 클라이언트에 발급된 모든 접근 토큰은 웹 서버에 저장되며, 리소스 소유자에게 노출되거나 접근 가능하지 않다. user-agent-based application 사용자 에이전트 기반 애플리케이션은 클라이언트 코드가 웹 서버에서 다운로드되어 리소스 소유자가 사용하는 장치의 사용자 에이전트(예: 웹 브라우저) 안에서 실행되는 public 클라이언트이다. 프로토콜 데이터와 자격 증명은 리소스 소유자가 쉽게 접근할 수 있으며(종종 볼 수도 있다). 이러한 애플리케이션은 사용자 에이전트 안에 있으므로, 인가를 요청할 때 사용자 에이전트 기능을 매끄럽게 사용할 수 있다. native application 네이티브 애플리케이션은 리소스 소유자가 사용하는 장치에 설치되어 실행되는 public 클라이언트이다. 프로토콜 데이터와 자격 증명은 리소스 소유자가 접근할 수 있다. 애플리케이션에 포함된 모든 클라이언트 인증 자격 증명은 추출될 수 있다고 가정한다. 반면, 접근 토큰이나 갱신 토큰과 같이 동적으로 발급되는 자격 증명은 허용 가능한 수준의 보호를 받을 수 있다. 최소한 이러한 자격 증명은 애플리케이션이 상호작용할 수 있는 악의적인 서버로부터 보호된다. 일부 플랫폼에서는 이러한 자격 증명이 같은 장치에 있는 다른 애플리케이션으로 부터 보호될 수 있다. 2.2. 클라이언트 식별자 인가 서버는 등록된 클라이언트에 클라이언트 식별자를 발급한다. 이는 클라이언트가 제공한 등록 정보를 나타내는 고유 문자열이다. 클라이언트 식별자는 비밀이 아니며, 리소스 소유자에게 노출되고 클라이언트 인증에 단독으로 사용되어서는 안 된다(MUST NOT). 클라이언트 식별자는 인가 서버에 대해 고유하다. 클라이언트 식별자 문자열의 크기는 이 명세에서 정의하지 않는다. 클라이언트는 식별자 크기에 대해 가정하지 않아야 한다. 인가 서버는 자신이 발급하는 모든 식별자의 크기를 문서화해야 한다 (SHOULD). Hardt 표준 트랙 [Page 15]
RFC 6749 OAuth 2.0 2012년 10월 2.3. 클라이언트 인증 클라이언트 유형이 confidential인 경우, 클라이언트와 인가 서버는 인가 서버의 보안 요구사항에 적합한 클라이언트 인증 방법을 설정한다. 인가 서버는 자신의 보안 요구사항을 충족하는 어떤 형태의 클라이언트 인증도 수락할 수 있다(MAY). Confidential 클라이언트는 일반적으로 인가 서버에 인증하는 데 사용되는 클라이언트 자격 증명 집합(예: 비밀번호, 공개/비공개 키 쌍)을 발급받거나 설정한다. 인가 서버는 public 클라이언트와 클라이언트 인증 방법을 설정할 수 있다(MAY). 그러나 인가 서버는 클라이언트를 식별하기 위한 목적으로 public 클라이언트 인증에 의존해서는 안 된다 (MUST NOT). 클라이언트는 각 요청에서 둘 이상의 인증 방법을 사용해서는 안 된다(MUST NOT). 2.3.1. 클라이언트 비밀번호 클라이언트 비밀번호를 보유한 클라이언트는 [RFC2617]에 정의된 HTTP Basic 인증 스킴을 사용하여 인가 서버에 인증할 수 있다(MAY). 클라이언트 식별자는 Appendix B에 따른 "application/x-www-form-urlencoded" 인코딩 알고리즘을 사용해 인코딩되고, 인코딩된 값은 사용자 이름으로 사용된다. 클라이언트 비밀번호도 같은 알고리즘으로 인코딩되어 비밀번호로 사용된다. 인가 서버는 클라이언트 비밀번호를 발급받은 클라이언트를 인증하기 위해 HTTP Basic 인증 스킴을 지원해야 한다(MUST). 예를 들어(표시 목적으로만 추가 줄바꿈 사용): Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 또는, 인가 서버는 다음 매개변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함하는 것을 지원할 수 있다(MAY). client_id REQUIRED. Section 2.2에 설명된 등록 과정에서 클라이언트에 발급된 클라이언트 식별자이다. client_secret REQUIRED. 클라이언트 비밀이다. 클라이언트 비밀이 빈 문자열이면 클라이언트는 이 매개변수를 생략할 수 있다 (MAY). Hardt 표준 트랙 [Page 16]
RFC 6749 OAuth 2.0 2012년 10월 두 매개변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함하는 것은 권장되지 않으며(NOT RECOMMENDED), HTTP Basic 인증 스킴(또는 기타 비밀번호 기반 HTTP 인증 스킴)을 직접 활용할 수 없는 클라이언트로 제한해야 한다(SHOULD). 이 매개변수는 요청 본문에서만 전송할 수 있으며 요청 URI에 포함되어서는 안 된다(MUST NOT). 예를 들어, 본문 매개변수를 사용하여 접근 토큰을 갱신하는 요청(Section 6)(표시 목적으로만 추가 줄바꿈 사용): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw 인가 서버는 비밀번호 인증을 사용하는 요청을 보낼 때 Section 1.6에 설명된 TLS 사용을 요구해야 한다(MUST). 이 클라이언트 인증 방법은 비밀번호를 포함하므로, 인가 서버는 이를 활용하는 모든 엔드포인트를 무차별 대입 공격으로부터 보호해야 한다(MUST). 2.3.2. 기타 인증 방법 인가 서버는 자신의 보안 요구사항에 맞는 적절한 HTTP 인증 스킴을 지원할 수 있다(MAY). 다른 인증 방법을 사용할 때, 인가 서버는 클라이언트 식별자(등록 레코드)와 인증 스킴 사이의 매핑을 정의해야 한다(MUST). 2.4. 등록되지 않은 클라이언트 이 명세는 등록되지 않은 클라이언트의 사용을 배제하지 않는다. 그러나 그러한 클라이언트의 사용은 이 명세의 범위를 벗어나며, 추가적인 보안 분석과 상호 운용성 영향 검토가 필요하다. Hardt 표준 트랙 [Page 17]
RFC 6749 OAuth 2.0 2012년 10월 3. 프로토콜 엔드포인트 인가 과정은 두 개의 인가 서버 엔드포인트(HTTP 리소스)를 활용한다. o 인가 엔드포인트 - 사용자 에이전트 리디렉션을 통해 리소스 소유자로부터 인가를 얻기 위해 클라이언트가 사용한다. o 토큰 엔드포인트 - 일반적으로 클라이언트 인증과 함께, 클라이언트가 인가 부여를 접근 토큰으로 교환하기 위해 사용한다. 또한 하나의 클라이언트 엔드포인트도 활용한다. o 리디렉션 엔드포인트 - 인가 서버가 리소스 소유자의 사용자 에이전트를 통해 인가 자격 증명을 포함한 응답을 클라이언트에 반환하기 위해 사용한다. 모든 인가 부여 유형이 두 엔드포인트를 모두 활용하는 것은 아니다. 확장 부여 유형은 필요에 따라 추가 엔드포인트를 정의할 수 있다(MAY). 3.1. 인가 엔드포인트 인가 엔드포인트는 리소스 소유자와 상호작용하고 인가 부여를 얻는 데 사용된다. 인가 서버는 먼저 리소스 소유자의 신원을 확인해야 한다(MUST). 인가 서버가 리소스 소유자를 인증하는 방식(예: 사용자 이름과 비밀번호 로그인, 세션 쿠키)은 이 명세의 범위를 벗어난다. 클라이언트가 인가 엔드포인트의 위치를 얻는 수단은 이 명세의 범위를 벗어나지만, 일반적으로 서비스 문서에서 제공된다. 엔드포인트 URI는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식의 질의 구성요소([RFC3986] Section 3.4)를 포함할 수 있으며(MAY), 추가 질의 매개변수를 추가할 때 이를 유지해야 한다(MUST). 엔드포인트 URI는 프래그먼트 구성요소를 포함해서는 안 된다 (MUST NOT). 인가 엔드포인트로의 요청은 사용자 인증과 평문 자격 증명의 전송(HTTP 응답 안에서)을 초래하므로, 인가 서버는 인가 엔드포인트에 요청을 보낼 때 Section 1.6에 설명된 TLS 사용을 요구해야 한다(MUST). 인가 서버는 인가 엔드포인트에 대해 HTTP "GET" 메서드 [RFC2616]의 사용을 지원해야 하며(MUST), "POST" 메서드의 사용도 지원할 수 있다(MAY). Hardt 표준 트랙 [Page 18]
RFC 6749 OAuth 2.0 2012년 10월 값 없이 전송된 매개변수는 요청에서 생략된 것처럼 처리해야 한다(MUST). 인가 서버는 인식하지 못한 요청 매개변수를 무시해야 한다(MUST). 요청 및 응답 매개변수는 한 번을 초과하여 포함되어서는 안 된다(MUST NOT). 3.1.1. 응답 유형 인가 엔드포인트는 인가 코드 부여 유형 및 암시적 부여 유형 흐름에서 사용된다. 클라이언트는 다음 매개변수를 사용하여 원하는 부여 유형을 인가 서버에 알린다. response_type REQUIRED. 값은 Section 4.1.1에 설명된 인가 코드를 요청하기 위한 "code", Section 4.2.1에 설명된 접근 토큰(암시적 부여)을 요청하기 위한 "token", 또는 Section 8.4에 설명된 등록된 확장 값 중 하나여야 한다(MUST). 확장 응답 유형은 공백으로 구분된(%x20) 값 목록을 포함할 수 있으며(MAY), 이때 값의 순서는 중요하지 않다(예: 응답 유형 "a b"는 "b a"와 같다). 이러한 복합 응답 유형의 의미는 각각의 명세에서 정의된다. 인가 요청에 "response_type" 매개변수가 없거나 응답 유형을 이해할 수 없는 경우, 인가 서버는 Section 4.1.2.1에 설명된 오류 응답을 반환해야 한다(MUST). 3.1.2. 리디렉션 엔드포인트 리소스 소유자와의 상호작용을 완료한 후, 인가 서버는 리소스 소유자의 사용자 에이전트를 다시 클라이언트로 안내한다. 인가 서버는 클라이언트 등록 과정 중 또는 인가 요청을 할 때 인가 서버와 사전에 설정된 클라이언트의 리디렉션 엔드포인트로 사용자 에이전트를 리디렉션한다. 리디렉션 엔드포인트 URI는 [RFC3986] Section 4.3에 정의된 절대 URI여야 한다(MUST). 엔드포인트 URI는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식의 질의 구성요소 ([RFC3986] Section 3.4)를 포함할 수 있으며(MAY), 추가 질의 매개변수를 추가할 때 이를 유지해야 한다(MUST). 엔드포인트 URI는 프래그먼트 구성요소를 포함해서는 안 된다(MUST NOT). Hardt 표준 트랙 [Page 19]
RFC 6749 OAuth 2.0 2012년 10월 3.1.2.1. 엔드포인트 요청 기밀성 리디렉션 엔드포인트는 요청된 응답 유형이 "code" 또는 "token"일 때, 또는 리디렉션 요청이 공개 네트워크를 통한 민감한 자격 증명의 전송을 초래할 때 Section 1.6에 설명된 TLS 사용을 요구해야 한다(SHOULD). 이 명세는 TLS 사용을 의무화하지 않는다. 왜냐하면 이 글을 쓰는 시점에 클라이언트가 TLS를 배포하도록 요구하는 것은 많은 클라이언트 개발자에게 상당한 장애물이기 때문이다. TLS를 사용할 수 없는 경우, 인가 서버는 리디렉션 전에 리소스 소유자에게 안전하지 않은 엔드포인트에 대해 경고해야 한다(SHOULD)(예: 인가 요청 중 메시지를 표시). 전송 계층 보안의 부재는 클라이언트와 그 클라이언트가 접근 권한을 부여받은 보호된 리소스의 보안에 심각한 영향을 미칠 수 있다. 전송 계층 보안의 사용은 인가 과정이 클라이언트에 의한 위임된 최종 사용자 인증의 한 형태로 사용될 때(예: 서드파티 로그인 서비스) 특히 중요하다. 3.1.2.2. 등록 요구사항 인가 서버는 다음 클라이언트가 리디렉션 엔드포인트를 등록하도록 요구해야 한다(MUST). o Public 클라이언트. o 암시적 부여 유형을 활용하는 confidential 클라이언트. 인가 서버는 모든 클라이언트가 인가 엔드포인트를 활용하기 전에 리디렉션 엔드포인트를 등록하도록 요구해야 한다(SHOULD). 인가 서버는 클라이언트가 완전한 리디렉션 URI를 제공하도록 요구해야 한다(SHOULD)(클라이언트는 요청별 사용자 지정을 달성하기 위해 "state" 요청 매개변수를 사용할 수 있다(MAY)). 완전한 리디렉션 URI의 등록을 요구할 수 없는 경우, 인가 서버는 URI scheme, authority, path의 등록을 요구해야 한다(SHOULD) (클라이언트가 인가를 요청할 때 리디렉션 URI의 질의 구성요소만 동적으로 변경할 수 있도록 허용). 인가 서버는 클라이언트가 여러 리디렉션 엔드포인트를 등록하는 것을 허용할 수 있다(MAY). 리디렉션 URI 등록 요구사항이 없으면, 공격자가 Section 10.15에 설명된 것처럼 인가 엔드포인트를 오픈 리디렉터로 사용할 수 있게 될 수 있다. Hardt 표준 트랙 [Page 20]
RFC 6749 OAuth 2.0 2012년 10월 3.1.2.3. 동적 구성 여러 리디렉션 URI가 등록되었거나, 리디렉션 URI의 일부만 등록되었거나, 리디렉션 URI가 등록되지 않은 경우, 클라이언트는 "redirect_uri" 요청 매개변수를 사용하여 인가 요청에 리디렉션 URI를 포함해야 한다(MUST). 인가 요청에 리디렉션 URI가 포함된 경우, 인가 서버는 등록된 리디렉션 URI가 있다면 [RFC3986] Section 6에 정의된 대로 수신한 값을 등록된 리디렉션 URI(또는 URI 구성요소) 중 적어도 하나와 비교하고 일치시켜야 한다(MUST). 클라이언트 등록에 전체 리디렉션 URI가 포함된 경우, 인가 서버는 [RFC3986] Section 6.2.1에 정의된 단순 문자열 비교를 사용하여 두 URI를 비교해야 한다(MUST). 3.1.2.4. 유효하지 않은 엔드포인트 누락되었거나 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 인가 요청 검증이 실패하는 경우, 인가 서버는 리소스 소유자에게 오류를 알려야 하며(SHOULD), 유효하지 않은 리디렉션 URI로 사용자 에이전트를 자동으로 리디렉션해서는 안 된다(MUST NOT). 3.1.2.5. 엔드포인트 콘텐츠 클라이언트 엔드포인트로의 리디렉션 요청은 일반적으로 사용자 에이전트가 처리하는 HTML 문서 응답을 초래한다. HTML 응답이 리디렉션 요청의 결과로 직접 제공되는 경우, HTML 문서에 포함된 모든 스크립트는 리디렉션 URI와 그 안에 포함된 자격 증명에 대한 전체 접근 권한으로 실행된다. 클라이언트는 리디렉션 엔드포인트 응답에 서드파티 스크립트 (예: 서드파티 분석, 소셜 플러그인, 광고 네트워크)를 포함해서는 안 된다(SHOULD NOT). 대신 URI에서 자격 증명을 추출하고, 자격 증명을 노출하지 않은 채(URI 안이나 다른 곳에서) 사용자 에이전트를 다시 다른 엔드포인트로 리디렉션해야 한다 (SHOULD). 서드파티 스크립트가 포함되는 경우, 클라이언트는 자신의 스크립트(URI에서 자격 증명을 추출하고 제거하는 데 사용되는)가 먼저 실행되도록 보장해야 한다(MUST). 3.2. 토큰 엔드포인트 토큰 엔드포인트는 클라이언트가 자신의 인가 부여 또는 갱신 토큰을 제시하여 접근 토큰을 얻는 데 사용된다. 토큰 엔드포인트는 접근 토큰이 직접 발급되는 암시적 부여 유형을 제외한 모든 인가 부여와 함께 사용된다. Hardt 표준 트랙 [Page 21]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트가 토큰 엔드포인트의 위치를 얻는 수단은 이 명세의 범위를 벗어나지만, 일반적으로 서비스 문서에서 제공된다. 엔드포인트 URI는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식의 질의 구성요소 ([RFC3986] Section 3.4)를 포함할 수 있으며(MAY), 추가 질의 매개변수를 추가할 때 이를 유지해야 한다(MUST). 엔드포인트 URI는 프래그먼트 구성요소를 포함해서는 안 된다(MUST NOT). 토큰 엔드포인트로의 요청은 평문 자격 증명의 전송(HTTP 요청과 응답 안에서)을 초래하므로, 인가 서버는 토큰 엔드포인트에 요청을 보낼 때 Section 1.6에 설명된 TLS 사용을 요구해야 한다(MUST). 클라이언트는 접근 토큰 요청을 할 때 HTTP "POST" 메서드를 사용해야 한다(MUST). 값 없이 전송된 매개변수는 요청에서 생략된 것처럼 처리해야 한다(MUST). 인가 서버는 인식하지 못한 요청 매개변수를 무시해야 한다(MUST). 요청 및 응답 매개변수는 한 번을 초과하여 포함되어서는 안 된다(MUST NOT). 3.2.1. 클라이언트 인증 Confidential 클라이언트 또는 클라이언트 자격 증명을 발급받은 기타 클라이언트는 토큰 엔드포인트에 요청할 때 Section 2.3에 설명된 대로 인가 서버에 인증해야 한다(MUST). 클라이언트 인증은 다음을 위해 사용된다. o 갱신 토큰과 인가 코드가 그것을 발급받은 클라이언트에 결합되도록 강제한다. 인가 코드가 안전하지 않은 채널을 통해 리디렉션 엔드포인트로 전송되거나 리디렉션 URI가 전체로 등록되지 않은 경우, 클라이언트 인증은 매우 중요하다. o 클라이언트를 비활성화하거나 그 자격 증명을 변경함으로써 침해된 클라이언트에서 복구하고, 이를 통해 공격자가 도난당한 갱신 토큰을 악용하지 못하게 한다. 단일 클라이언트 자격 증명 집합을 변경하는 것은 전체 갱신 토큰 집합을 폐기하는 것보다 훨씬 빠르다. o 주기적인 자격 증명 교체를 요구하는 인증 관리 모범 사례를 구현한다. 전체 갱신 토큰 집합의 교체는 어려울 수 있지만, 단일 클라이언트 자격 증명 집합의 교체는 훨씬 쉽다. Hardt 표준 트랙 [Page 22]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트는 토큰 엔드포인트에 요청을 보낼 때 자신을 식별하기 위해 "client_id" 요청 매개변수를 사용할 수 있다(MAY). 토큰 엔드포인트로의 "authorization_code" "grant_type" 요청에서, 인증되지 않은 클라이언트는 다른 "client_id"를 가진 클라이언트를 위해 의도된 코드를 실수로 수락하지 않도록 자신의 "client_id"를 보내야 한다(MUST). 이는 인증 코드의 대체로부터 클라이언트를 보호한다. (보호된 리소스에는 추가 보안을 제공하지 않는다.) 3.3. 접근 토큰 범위 인가 엔드포인트와 토큰 엔드포인트는 클라이언트가 "scope" 요청 매개변수를 사용하여 접근 요청의 범위를 지정할 수 있게 한다. 이어서 인가 서버는 "scope" 응답 매개변수를 사용하여 발급된 접근 토큰의 범위를 클라이언트에 알린다. scope 매개변수의 값은 공백으로 구분된 대소문자 구분 문자열 목록으로 표현된다. 이 문자열은 인가 서버가 정의한다. 값이 여러 개의 공백 구분 문자열을 포함하는 경우, 그 순서는 중요하지 않으며 각 문자열은 요청된 범위에 추가 접근 범위를 더한다. scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) 인가 서버는 인가 서버 정책 또는 리소스 소유자의 지시에 따라 클라이언트가 요청한 scope를 전체 또는 부분적으로 무시할 수 있다(MAY). 발급된 접근 토큰 범위가 클라이언트가 요청한 것과 다른 경우, 인가 서버는 실제로 부여된 범위를 클라이언트에 알리기 위해 "scope" 응답 매개변수를 포함해야 한다(MUST). 클라이언트가 인가를 요청할 때 scope 매개변수를 생략하는 경우, 인가 서버는 미리 정의된 기본값을 사용하여 요청을 처리하거나 유효하지 않은 scope를 표시하며 요청을 실패시켜야 한다(MUST). 인가 서버는 자신의 scope 요구사항과 기본값(정의된 경우)을 문서화해야 한다(SHOULD). 4. 인가 획득 접근 토큰을 요청하기 위해, 클라이언트는 리소스 소유자로부터 인가를 얻는다. 인가는 인가 부여의 형태로 표현되며, 클라이언트는 이를 사용하여 접근 토큰을 요청한다. OAuth는 네 가지 부여 유형, 즉 인가 코드, 암시적, 리소스 소유자 비밀번호 자격 증명, 클라이언트 자격 증명을 정의한다. 또한 추가 부여 유형을 정의하기 위한 확장 메커니즘도 제공한다. Hardt 표준 트랙 [Page 23]
RFC 6749 OAuth 2.0 2012년 10월 4.1. 인가 코드 부여 인가 코드 부여 유형은 접근 토큰과 갱신 토큰을 모두 얻는 데 사용되며 confidential 클라이언트에 최적화되어 있다. 이는 리디렉션 기반 흐름이므로, 클라이언트는 리소스 소유자의 사용자 에이전트(일반적으로 웹 브라우저)와 상호작용할 수 있어야 하며, 인가 서버로부터 들어오는 요청을(리디렉션을 통해) 받을 수 있어야 한다. +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI ---->| | | User- | | Authorization | | Agent -+----(B)-- User authenticates --->| Server | | | | | | -+----(C)-- Authorization Code ---<| | +-|----|---+ +---------------+ | | ^ v (A) (C) | | | | | | ^ v | | +---------+ | | | |>---(D)-- Authorization Code ---------' | | Client | & Redirection URI | | | | | |<---(E)----- Access Token -------------------' +---------+ (w/ Optional Refresh Token) 참고: 단계 (A), (B), (C)를 나타내는 선은 사용자 에이전트를 통과하기 때문에 두 부분으로 나뉘어 있다. 그림 3: 인가 코드 흐름 Hardt 표준 트랙 [Page 24]
RFC 6749 OAuth 2.0 2012년 10월 그림 3에 표시된 흐름은 다음 단계를 포함한다. (A) 클라이언트는 리소스 소유자의 사용자 에이전트를 인가 엔드포인트로 안내하여 흐름을 시작한다. 클라이언트는 자신의 클라이언트 식별자, 요청된 scope, 로컬 상태, 그리고 접근이 부여되거나 거부된 후 인가 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI를 포함한다. (B) 인가 서버는 (사용자 에이전트를 통해) 리소스 소유자를 인증하고, 리소스 소유자가 클라이언트의 접근 요청을 허가하는지 거부하는지를 결정한다. (C) 리소스 소유자가 접근을 허가한다고 가정하면, 인가 서버는 앞서 제공된 리디렉션 URI(요청 중 또는 클라이언트 등록 중)를 사용하여 사용자 에이전트를 다시 클라이언트로 리디렉션한다. 리디렉션 URI에는 인가 코드와 클라이언트가 앞서 제공한 모든 로컬 상태가 포함된다. (D) 클라이언트는 이전 단계에서 받은 인가 코드를 포함하여 인가 서버의 토큰 엔드포인트에 접근 토큰을 요청한다. 요청할 때, 클라이언트는 인가 서버에 인증한다. 클라이언트는 검증을 위해 인가 코드를 얻는 데 사용된 리디렉션 URI를 포함한다. (E) 인가 서버는 클라이언트를 인증하고, 인가 코드를 검증하며, 수신한 리디렉션 URI가 단계 (C)에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인한다. 유효하면, 인가 서버는 접근 토큰과 선택적으로 갱신 토큰을 응답으로 반환한다. 4.1.1. 인가 요청 클라이언트는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 인가 엔드포인트 URI의 질의 구성요소에 다음 매개변수를 추가함으로써 요청 URI를 구성한다. response_type REQUIRED. 값은 "code"로 설정해야 한다(MUST). client_id REQUIRED. Section 2.2에 설명된 클라이언트 식별자이다. redirect_uri OPTIONAL. Section 3.1.2에 설명된 바와 같다. Hardt 표준 트랙 [Page 25]
RFC 6749 OAuth 2.0 2012년 10월 scope OPTIONAL. Section 3.3에 설명된 접근 요청의 범위이다. state RECOMMENDED. 요청과 콜백 사이에서 상태를 유지하기 위해 클라이언트가 사용하는 불투명한 값이다. 인가 서버는 사용자 에이전트를 다시 클라이언트로 리디렉션할 때 이 값을 포함한다. 이 매개변수는 Section 10.12에 설명된 사이트 간 요청 위조를 방지하기 위해 사용해야 한다(SHOULD). 클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 수단으로 리소스 소유자를 구성된 URI로 안내한다. 예를 들어, 클라이언트는 TLS를 사용하여 사용자 에이전트가 다음 HTTP 요청을 하도록 안내한다(표시 목적으로만 추가 줄바꿈 사용). GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 인가 서버는 모든 필수 매개변수가 존재하고 유효한지 확인하기 위해 요청을 검증한다. 요청이 유효하면, 인가 서버는 리소스 소유자를 인증하고 인가 결정을 얻는다(리소스 소유자에게 묻거나 다른 수단으로 승인을 설정하여). 결정이 설정되면, 인가 서버는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 수단으로 사용자 에이전트를 제공된 클라이언트 리디렉션 URI로 안내한다. 4.1.2. 인가 응답 리소스 소유자가 접근 요청을 허가하면, 인가 서버는 인가 코드를 발급하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 질의 구성요소에 다음 매개변수를 추가함으로써 이를 클라이언트에 전달한다. code REQUIRED. 인가 서버가 생성한 인가 코드이다. 인가 코드는 누출 위험을 완화하기 위해 발급된 직후 만료되어야 한다 (MUST). 인가 코드의 최대 수명은 10분을 권장한다 (RECOMMENDED). 클라이언트는 인가 코드를 한 번을 초과하여 Hardt 표준 트랙 [Page 26]
RFC 6749 OAuth 2.0 2012년 10월 사용해서는 안 된다(MUST NOT). 인가 코드가 한 번을 초과하여 사용되는 경우, 인가 서버는 요청을 거부해야 하며(MUST), 가능하면 그 인가 코드를 기반으로 이전에 발급된 모든 토큰을 폐기해야 한다(SHOULD). 인가 코드는 클라이언트 식별자 및 리디렉션 URI에 결합된다. state 클라이언트 인가 요청에 "state" 매개변수가 있었던 경우 REQUIRED. 클라이언트에서 수신한 정확한 값이다. 예를 들어, 인가 서버는 다음 HTTP 응답을 보내 사용자 에이전트를 리디렉션한다. HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz 클라이언트는 인식하지 못한 응답 매개변수를 무시해야 한다(MUST). 인가 코드 문자열의 크기는 이 명세에서 정의하지 않는다. 클라이언트는 코드 값 크기에 대해 가정하지 않아야 한다. 인가 서버는 자신이 발급하는 모든 값의 크기를 문서화해야 한다 (SHOULD). 4.1.2.1. 오류 응답 누락되었거나 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 요청이 실패하거나, 클라이언트 식별자가 없거나 유효하지 않은 경우, 인가 서버는 리소스 소유자에게 오류를 알려야 하며(SHOULD), 유효하지 않은 리디렉션 URI로 사용자 에이전트를 자동으로 리디렉션해서는 안 된다(MUST NOT). 리소스 소유자가 접근 요청을 거부하거나, 누락되었거나 유효하지 않은 리디렉션 URI 이외의 이유로 요청이 실패하는 경우, 인가 서버는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 질의 구성요소에 다음 매개변수를 추가함으로써 클라이언트에 알린다. error REQUIRED. 다음 중 하나인 단일 ASCII [USASCII] 오류 코드이다. invalid_request 요청에 필수 매개변수가 없거나, 유효하지 않은 매개변수 값이 포함되어 있거나, 매개변수가 두 번 이상 포함되어 있거나, 그 밖에 형식이 잘못되었다. Hardt 표준 트랙 [Page 27]
RFC 6749 OAuth 2.0 2012년 10월 unauthorized_client 클라이언트가 이 방법을 사용하여 인가 코드를 요청할 권한이 없다. access_denied 리소스 소유자 또는 인가 서버가 요청을 거부했다. unsupported_response_type 인가 서버가 이 방법을 사용한 인가 코드 획득을 지원하지 않는다. invalid_scope 요청된 scope가 유효하지 않거나, 알 수 없거나, 형식이 잘못되었다. server_error 인가 서버가 요청을 이행하지 못하게 하는 예기치 않은 조건을 만났다. (500 Internal Server Error HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요하다.) temporarily_unavailable 서버의 일시적 과부하 또는 유지보수로 인해 인가 서버가 현재 요청을 처리할 수 없다. (503 Service Unavailable HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요하다.) "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_description OPTIONAL. 발생한 오류를 클라이언트 개발자가 이해하는 데 도움을 주기 위해 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII [USASCII] 텍스트이다. "error_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_uri OPTIONAL. 오류에 대한 정보가 있는 사람이 읽을 수 있는 웹 페이지를 식별하는 URI이며, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용된다. "error_uri" 매개변수의 값은 URI-reference 구문을 준수해야 하며(MUST), 따라서 %x21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). Hardt 표준 트랙 [Page 28]
RFC 6749 OAuth 2.0 2012년 10월 state 클라이언트 인가 요청에 "state" 매개변수가 있었던 경우 REQUIRED. 클라이언트에서 수신한 정확한 값이다. 예를 들어, 인가 서버는 다음 HTTP 응답을 보내 사용자 에이전트를 리디렉션한다. HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz 4.1.3. 접근 토큰 요청 클라이언트는 HTTP 요청 entity-body에서 UTF-8 문자 인코딩을 사용하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식으로 다음 매개변수를 보내 토큰 엔드포인트에 요청한다. grant_type REQUIRED. 값은 "authorization_code"로 설정해야 한다(MUST). code REQUIRED. 인가 서버에서 받은 인가 코드이다. redirect_uri Section 4.1.1에 설명된 대로 인가 요청에 "redirect_uri" 매개변수가 포함된 경우 REQUIRED이며, 그 값은 동일해야 한다(MUST). client_id 클라이언트가 Section 3.2.1에 설명된 대로 인가 서버에 인증하지 않는 경우 REQUIRED. 클라이언트 유형이 confidential이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우(또는 다른 인증 요구사항이 할당된 경우), 클라이언트는 Section 3.2.1에 설명된 대로 인가 서버에 인증해야 한다(MUST). Hardt 표준 트랙 [Page 29]
RFC 6749 OAuth 2.0 2012년 10월 예를 들어, 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 한다 (표시 목적으로만 추가 줄바꿈 사용). POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 인가 서버는 다음을 수행해야 한다(MUST). o confidential 클라이언트 또는 클라이언트 자격 증명을 발급받은 모든 클라이언트(또는 기타 인증 요구사항이 있는 클라이언트)에 대해 클라이언트 인증을 요구한다. o 클라이언트 인증이 포함된 경우 클라이언트를 인증한다. o 인가 코드가 인증된 confidential 클라이언트에 발급되었는지 확인하거나, 클라이언트가 public인 경우 코드가 요청의 "client_id"에 발급되었는지 확인한다. o 인가 코드가 유효한지 검증한다. 그리고 o Section 4.1.1에 설명된 대로 최초 인가 요청에 "redirect_uri" 매개변수가 포함된 경우 "redirect_uri" 매개변수가 존재하는지 확인하고, 포함된 경우 그 값이 동일한지 확인한다. 4.1.4. 접근 토큰 응답 접근 토큰 요청이 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰과 선택적 갱신 토큰을 발급한다. 요청 클라이언트 인증이 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. Hardt 표준 트랙 [Page 30]
RFC 6749 OAuth 2.0 2012년 10월 성공 응답의 예: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" } 4.2. 암시적 부여 암시적 부여 유형은 접근 토큰을 얻는 데 사용되며(갱신 토큰 발급은 지원하지 않음), 특정 리디렉션 URI를 운영하는 것으로 알려진 public 클라이언트에 최적화되어 있다. 이러한 클라이언트는 일반적으로 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현된다. 이는 리디렉션 기반 흐름이므로, 클라이언트는 리소스 소유자의 사용자 에이전트(일반적으로 웹 브라우저)와 상호작용할 수 있어야 하며, 인가 서버로부터 들어오는 요청을(리디렉션을 통해) 받을 수 있어야 한다. 클라이언트가 인가와 접근 토큰을 위해 별도의 요청을 하는 인가 코드 부여 유형과 달리, 클라이언트는 인가 요청의 결과로 접근 토큰을 받는다. 암시적 부여 유형은 클라이언트 인증을 포함하지 않으며, 리소스 소유자의 존재와 리디렉션 URI의 등록에 의존한다. 접근 토큰은 리디렉션 URI에 인코딩되므로, 리소스 소유자와 같은 장치에 있는 다른 애플리케이션에 노출될 수 있다. Hardt 표준 트랙 [Page 31]
RFC 6749 OAuth 2.0 2012년 10월 +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)--- Redirection URI ----<| | | | with Access Token +---------------+ | | in Fragment | | +---------------+ | |----(D)--- Redirection URI ---->| Web-Hosted | | | without Fragment | Client | | | | Resource | | (F) |<---(E)------- Script ---------<| | | | +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ 참고: 단계 (A)와 (B)를 나타내는 선은 사용자 에이전트를 통과하기 때문에 두 부분으로 나뉘어 있다. 그림 4: 암시적 부여 흐름 Hardt 표준 트랙 [Page 32]
RFC 6749 OAuth 2.0 2012년 10월 그림 4에 표시된 흐름은 다음 단계를 포함한다. (A) 클라이언트는 리소스 소유자의 사용자 에이전트를 인가 엔드포인트로 안내하여 흐름을 시작한다. 클라이언트는 자신의 클라이언트 식별자, 요청된 scope, 로컬 상태, 그리고 접근이 부여되거나 거부된 후 인가 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI를 포함한다. (B) 인가 서버는 (사용자 에이전트를 통해) 리소스 소유자를 인증하고, 리소스 소유자가 클라이언트의 접근 요청을 허가하는지 거부하는지를 결정한다. (C) 리소스 소유자가 접근을 허가한다고 가정하면, 인가 서버는 앞서 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 다시 클라이언트로 리디렉션한다. 리디렉션 URI는 URI 프래그먼트 안에 접근 토큰을 포함한다. (D) 사용자 에이전트는 웹 호스팅 클라이언트 리소스에 요청을 하여 리디렉션 지시를 따른다([RFC2616]에 따라 프래그먼트는 포함되지 않음). 사용자 에이전트는 프래그먼트 정보를 로컬에 보관한다. (E) 웹 호스팅 클라이언트 리소스는 사용자 에이전트가 보관한 프래그먼트를 포함한 전체 리디렉션 URI에 접근하고, 그 프래그먼트에 포함된 접근 토큰(및 기타 매개변수)을 추출할 수 있는 웹 페이지(일반적으로 내장 스크립트가 있는 HTML 문서)를 반환한다. (F) 사용자 에이전트는 웹 호스팅 클라이언트 리소스가 제공한 스크립트를 로컬에서 실행하여 접근 토큰을 추출한다. (G) 사용자 에이전트는 접근 토큰을 클라이언트에 전달한다. 암시적 부여 사용에 대한 배경은 1.3.2절과 9절을 참조하라. 암시적 부여를 사용할 때의 중요한 보안 고려사항은 10.3절과 10.16절을 참조하라. 4.2.1. 인가 요청 클라이언트는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 인가 엔드포인트 URI의 질의 구성요소에 다음 매개변수를 추가함으로써 요청 URI를 구성한다. response_type REQUIRED. 값은 "token"으로 설정해야 한다(MUST). client_id REQUIRED. Section 2.2에 설명된 클라이언트 식별자이다. Hardt 표준 트랙 [Page 33]
RFC 6749 OAuth 2.0 2012년 10월 redirect_uri OPTIONAL. Section 3.1.2에 설명된 바와 같다. scope OPTIONAL. Section 3.3에 설명된 접근 요청의 범위이다. state RECOMMENDED. 요청과 콜백 사이에서 상태를 유지하기 위해 클라이언트가 사용하는 불투명한 값이다. 인가 서버는 사용자 에이전트를 다시 클라이언트로 리디렉션할 때 이 값을 포함한다. 이 매개변수는 Section 10.12에 설명된 사이트 간 요청 위조를 방지하기 위해 사용해야 한다(SHOULD). 클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 수단으로 리소스 소유자를 구성된 URI로 안내한다. 예를 들어, 클라이언트는 TLS를 사용하여 사용자 에이전트가 다음 HTTP 요청을 하도록 안내한다(표시 목적으로만 추가 줄바꿈 사용). GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 인가 서버는 모든 필수 매개변수가 존재하고 유효한지 확인하기 위해 요청을 검증한다. 인가 서버는 접근 토큰을 리디렉션할 리디렉션 URI가 Section 3.1.2에 설명된 대로 클라이언트가 등록한 리디렉션 URI와 일치하는지 검증해야 한다(MUST). 요청이 유효하면, 인가 서버는 리소스 소유자를 인증하고 인가 결정을 얻는다(리소스 소유자에게 묻거나 다른 수단으로 승인을 설정하여). 결정이 설정되면, 인가 서버는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 수단으로 사용자 에이전트를 제공된 클라이언트 리디렉션 URI로 안내한다. Hardt 표준 트랙 [Page 34]
RFC 6749 OAuth 2.0 2012년 10월 4.2.2. 접근 토큰 응답 리소스 소유자가 접근 요청을 허가하면, 인가 서버는 접근 토큰을 발급하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 프래그먼트 구성요소에 다음 매개변수를 추가함으로써 이를 클라이언트에 전달한다. access_token REQUIRED. 인가 서버가 발급한 접근 토큰이다. token_type REQUIRED. Section 7.1에 설명된 발급된 토큰의 유형이다. 값은 대소문자를 구분하지 않는다. expires_in RECOMMENDED. 접근 토큰의 수명(초)이다. 예를 들어 값 "3600"은 응답이 생성된 시점으로부터 한 시간 후 접근 토큰이 만료됨을 나타낸다. 생략된 경우, 인가 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야 한다(SHOULD). scope 클라이언트가 요청한 scope와 동일한 경우 OPTIONAL이고, 그렇지 않으면 REQUIRED. Section 3.3에 설명된 접근 토큰의 범위이다. state 클라이언트 인가 요청에 "state" 매개변수가 있었던 경우 REQUIRED. 클라이언트에서 수신한 정확한 값이다. 인가 서버는 갱신 토큰을 발급해서는 안 된다(MUST NOT). 예를 들어, 인가 서버는 다음 HTTP 응답을 보내 사용자 에이전트를 리디렉션한다(표시 목적으로만 추가 줄바꿈 사용). HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600 개발자는 일부 사용자 에이전트가 HTTP "Location" 응답 헤더 필드에 프래그먼트 구성요소를 포함하는 것을 지원하지 않는다는 점에 유의해야 한다. 이러한 클라이언트는 3xx 리디렉션 응답 이외의 다른 방법으로 클라이언트를 리디렉션해야 한다. 예를 들어, 리디렉션 URI에 연결된 action을 가진 'continue' 버튼을 포함하는 HTML 페이지를 반환할 수 있다. Hardt 표준 트랙 [Page 35]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트는 인식하지 못한 응답 매개변수를 무시해야 한다(MUST). 접근 토큰 문자열의 크기는 이 명세에서 정의하지 않는다. 클라이언트는 값 크기에 대해 가정하지 않아야 한다. 인가 서버는 자신이 발급하는 모든 값의 크기를 문서화해야 한다(SHOULD). 4.2.2.1. 오류 응답 누락되었거나 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 요청이 실패하거나, 클라이언트 식별자가 없거나 유효하지 않은 경우, 인가 서버는 리소스 소유자에게 오류를 알려야 하며(SHOULD), 유효하지 않은 리디렉션 URI로 사용자 에이전트를 자동으로 리디렉션해서는 안 된다(MUST NOT). 리소스 소유자가 접근 요청을 거부하거나, 누락되었거나 유효하지 않은 리디렉션 URI 이외의 이유로 요청이 실패하는 경우, 인가 서버는 Appendix B에 따른 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 프래그먼트 구성요소에 다음 매개변수를 추가함으로써 클라이언트에 알린다. error REQUIRED. 다음 중 하나인 단일 ASCII [USASCII] 오류 코드이다. invalid_request 요청에 필수 매개변수가 없거나, 유효하지 않은 매개변수 값이 포함되어 있거나, 매개변수가 두 번 이상 포함되어 있거나, 그 밖에 형식이 잘못되었다. unauthorized_client 클라이언트가 이 방법을 사용하여 접근 토큰을 요청할 권한이 없다. access_denied 리소스 소유자 또는 인가 서버가 요청을 거부했다. unsupported_response_type 인가 서버가 이 방법을 사용한 접근 토큰 획득을 지원하지 않는다. invalid_scope 요청된 scope가 유효하지 않거나, 알 수 없거나, 형식이 잘못되었다. Hardt 표준 트랙 [Page 36]
RFC 6749 OAuth 2.0 2012년 10월 server_error 인가 서버가 요청을 이행하지 못하게 하는 예기치 않은 조건을 만났다. (500 Internal Server Error HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요하다.) temporarily_unavailable 서버의 일시적 과부하 또는 유지보수로 인해 인가 서버가 현재 요청을 처리할 수 없다. (503 Service Unavailable HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요하다.) "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_description OPTIONAL. 발생한 오류를 클라이언트 개발자가 이해하는 데 도움을 주기 위해 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII [USASCII] 텍스트이다. "error_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_uri OPTIONAL. 오류에 대한 정보가 있는 사람이 읽을 수 있는 웹 페이지를 식별하는 URI이며, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용된다. "error_uri" 매개변수의 값은 URI-reference 구문을 준수해야 하며(MUST), 따라서 %x21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). state 클라이언트 인가 요청에 "state" 매개변수가 있었던 경우 REQUIRED. 클라이언트에서 수신한 정확한 값이다. 예를 들어, 인가 서버는 다음 HTTP 응답을 보내 사용자 에이전트를 리디렉션한다. HTTP/1.1 302 Found Location: https://client.example.com/cb#error=access_denied&state=xyz 4.3. 리소스 소유자 비밀번호 자격 증명 부여 리소스 소유자 비밀번호 자격 증명 부여 유형은 리소스 소유자가 장치 운영 체제나 높은 권한을 가진 애플리케이션과 같이 Hardt 표준 트랙 [Page 37]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트와 신뢰 관계를 가진 경우에 적합하다. 인가 서버는 이 부여 유형을 활성화할 때 특별한 주의를 기울여야 하며, 다른 흐름이 실행 가능하지 않을 때에만 이를 허용해야 한다. 이 부여 유형은 리소스 소유자의 자격 증명(사용자 이름과 비밀번호, 일반적으로 대화형 양식을 사용)을 얻을 수 있는 클라이언트에 적합하다. 또한 HTTP Basic 또는 Digest 인증과 같은 직접 인증 스킴을 사용하는 기존 클라이언트를 OAuth로 마이그레이션할 때, 저장된 자격 증명을 접근 토큰으로 변환하는 데 사용된다. +----------+ | Resource | | Owner | | | +----------+ v | Resource Owner (A) Password Credentials | v +---------+ +---------------+ | |>--(B)---- Resource Owner ------->| | | | Password Credentials | Authorization | | Client | | Server | | |<--(C)---- Access Token ---------<| | | | (w/ Optional Refresh Token) | | +---------+ +---------------+ 그림 5: 리소스 소유자 비밀번호 자격 증명 흐름 그림 5에 표시된 흐름은 다음 단계를 포함한다. (A) 리소스 소유자는 클라이언트에 자신의 사용자 이름과 비밀번호를 제공한다. (B) 클라이언트는 리소스 소유자로부터 받은 자격 증명을 포함하여 인가 서버의 토큰 엔드포인트에 접근 토큰을 요청한다. 요청할 때 클라이언트는 인가 서버에 인증한다. (C) 인가 서버는 클라이언트를 인증하고 리소스 소유자 자격 증명을 검증하며, 유효하면 접근 토큰을 발급한다. Hardt 표준 트랙 [Page 38]
RFC 6749 OAuth 2.0 2012년 10월 4.3.1. 인가 요청 및 응답 클라이언트가 리소스 소유자 자격 증명을 얻는 방법은 이 명세의 범위를 벗어난다. 클라이언트는 접근 토큰을 얻은 후 자격 증명을 폐기해야 한다(MUST). 4.3.2. 접근 토큰 요청 클라이언트는 HTTP 요청 entity-body에서 UTF-8 문자 인코딩을 사용하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식으로 다음 매개변수를 추가하여 토큰 엔드포인트에 요청한다. grant_type REQUIRED. 값은 "password"로 설정해야 한다(MUST). username REQUIRED. 리소스 소유자 사용자 이름이다. password REQUIRED. 리소스 소유자 비밀번호이다. scope OPTIONAL. Section 3.3에 설명된 접근 요청의 범위이다. 클라이언트 유형이 confidential이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우(또는 다른 인증 요구사항이 할당된 경우), 클라이언트는 Section 3.2.1에 설명된 대로 인가 서버에 인증해야 한다(MUST). 예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 한다(표시 목적으로만 추가 줄바꿈 사용). POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w Hardt 표준 트랙 [Page 39]
RFC 6749 OAuth 2.0 2012년 10월 인가 서버는 다음을 수행해야 한다(MUST). o confidential 클라이언트 또는 클라이언트 자격 증명을 발급받은 모든 클라이언트(또는 기타 인증 요구사항이 있는 클라이언트)에 대해 클라이언트 인증을 요구한다. o 클라이언트 인증이 포함된 경우 클라이언트를 인증한다. 그리고 o 기존 비밀번호 검증 알고리즘을 사용하여 리소스 소유자 비밀번호 자격 증명을 검증한다. 이 접근 토큰 요청은 리소스 소유자의 비밀번호를 활용하므로, 인가 서버는 엔드포인트를 무차별 대입 공격으로부터 보호해야 한다(MUST)(예: 속도 제한 사용 또는 경고 생성). 4.3.3. 접근 토큰 응답 접근 토큰 요청이 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰과 선택적 갱신 토큰을 발급한다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. 성공 응답의 예: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" } 4.4. 클라이언트 자격 증명 부여 클라이언트가 자신의 제어 하에 있는 보호된 리소스, 또는 인가 서버와 사전에 조율된 다른 리소스 소유자의 보호된 리소스에 대한 접근을 요청하는 경우, 클라이언트는 자신의 클라이언트 자격 증명만(또는 지원되는 다른 인증 수단)을 사용하여 접근 토큰을 요청할 수 있다(그 방법은 이 명세의 범위를 벗어난다). Hardt 표준 트랙 [Page 40]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트 자격 증명 부여 유형은 confidential 클라이언트만 사용해야 한다(MUST). +---------+ +---------------+ | | | | | |>--(A)- Client Authentication --->| Authorization | | Client | | Server | | |<--(B)---- Access Token ---------<| | | | | | +---------+ +---------------+ 그림 6: 클라이언트 자격 증명 흐름 그림 6에 표시된 흐름은 다음 단계를 포함한다. (A) 클라이언트는 인가 서버에 인증하고 토큰 엔드포인트에 접근 토큰을 요청한다. (B) 인가 서버는 클라이언트를 인증하고, 유효하면 접근 토큰을 발급한다. 4.4.1. 인가 요청 및 응답 클라이언트 인증이 인가 부여로 사용되므로, 추가 인가 요청은 필요하지 않다. 4.4.2. 접근 토큰 요청 클라이언트는 HTTP 요청 entity-body에서 UTF-8 문자 인코딩을 사용하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식으로 다음 매개변수를 추가하여 토큰 엔드포인트에 요청한다. grant_type REQUIRED. 값은 "client_credentials"로 설정해야 한다(MUST). scope OPTIONAL. Section 3.3에 설명된 접근 요청의 범위이다. 클라이언트는 Section 3.2.1에 설명된 대로 인가 서버에 인증해야 한다(MUST). Hardt 표준 트랙 [Page 41]
RFC 6749 OAuth 2.0 2012년 10월 예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 한다(표시 목적으로만 추가 줄바꿈 사용). POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials 인가 서버는 클라이언트를 인증해야 한다(MUST). 4.4.3. 접근 토큰 응답 접근 토큰 요청이 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰을 발급한다. 갱신 토큰은 포함하지 않아야 한다(SHOULD NOT). 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. 성공 응답의 예: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" } 4.5. 확장 부여 클라이언트는 토큰 엔드포인트의 "grant_type" 매개변수 값으로 절대 URI(인가 서버가 정의함)를 사용하여 부여 유형을 지정하고, 필요한 추가 매개변수를 더함으로써 확장 부여 유형을 사용한다. Hardt 표준 트랙 [Page 42]
RFC 6749 OAuth 2.0 2012년 10월 예를 들어, [OAuth-SAML2]에 정의된 Security Assertion Markup Language (SAML) 2.0 assertion 부여 유형을 사용하여 접근 토큰을 요청하기 위해, 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 할 수 있다(표시 목적으로만 추가 줄바꿈 사용). POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 접근 토큰 요청이 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰과 선택적 갱신 토큰을 발급한다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. 5. 접근 토큰 발급 접근 토큰 요청이 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰과 선택적 갱신 토큰을 발급한다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. 5.1. 성공 응답 인가 서버는 접근 토큰과 선택적 갱신 토큰을 발급하고, HTTP 응답의 entity-body에 다음 매개변수를 추가하여 200 (OK) 상태 코드로 응답을 구성한다. access_token REQUIRED. 인가 서버가 발급한 접근 토큰이다. token_type REQUIRED. Section 7.1에 설명된 발급된 토큰의 유형이다. 값은 대소문자를 구분하지 않는다. expires_in RECOMMENDED. 접근 토큰의 수명(초)이다. 예를 들어 값 "3600"은 응답이 생성된 시점으로부터 한 시간 후 접근 토큰이 만료됨을 나타낸다. 생략된 경우, 인가 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야 한다(SHOULD). Hardt 표준 트랙 [Page 43]
RFC 6749 OAuth 2.0 2012년 10월 refresh_token OPTIONAL. Section 6에 설명된 대로 같은 인가 부여를 사용하여 새 접근 토큰을 얻는 데 사용할 수 있는 갱신 토큰이다. scope 클라이언트가 요청한 scope와 동일한 경우 OPTIONAL이고, 그렇지 않으면 REQUIRED. Section 3.3에 설명된 접근 토큰의 범위이다. 매개변수는 [RFC4627]에 정의된 "application/json" 미디어 유형을 사용하여 HTTP 응답의 entity-body에 포함된다. 매개변수는 각 매개변수를 최상위 구조 수준에 추가함으로써 JavaScript Object Notation (JSON) 구조로 직렬화된다. 매개변수 이름과 문자열 값은 JSON 문자열로 포함된다. 숫자 값은 JSON 숫자로 포함된다. 매개변수의 순서는 중요하지 않으며 달라질 수 있다. 인가 서버는 토큰, 자격 증명 또는 기타 민감한 정보를 포함하는 모든 응답에 값이 "no-store"인 HTTP "Cache-Control" 응답 헤더 필드 [RFC2616]와, 값이 "no-cache"인 "Pragma" 응답 헤더 필드 [RFC2616]를 포함해야 한다(MUST). 예: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" } 클라이언트는 응답에서 인식하지 못한 값 이름을 무시해야 한다 (MUST). 인가 서버에서 받은 토큰 및 기타 값의 크기는 정의되어 있지 않다. 클라이언트는 값 크기에 대해 가정하지 않아야 한다. 인가 서버는 자신이 발급하는 모든 값의 크기를 문서화해야 한다 (SHOULD). Hardt 표준 트랙 [Page 44]
RFC 6749 OAuth 2.0 2012년 10월 5.2. 오류 응답 인가 서버는 HTTP 400 (Bad Request) 상태 코드로 응답하고 (달리 지정되지 않는 한), 응답에 다음 매개변수를 포함한다. error REQUIRED. 다음 중 하나인 단일 ASCII [USASCII] 오류 코드이다. invalid_request 요청에 필수 매개변수가 없거나, 지원되지 않는 매개변수 값(부여 유형 제외)이 포함되어 있거나, 매개변수가 반복되거나, 여러 자격 증명이 포함되어 있거나, 클라이언트를 인증하기 위해 둘 이상의 메커니즘을 활용하거나, 그 밖에 형식이 잘못되었다. invalid_client 클라이언트 인증이 실패했다(예: 알 수 없는 클라이언트, 클라이언트 인증이 포함되지 않음, 또는 지원되지 않는 인증 방법). 인가 서버는 지원되는 HTTP 인증 스킴을 나타내기 위해 HTTP 401 (Unauthorized) 상태 코드를 반환할 수 있다(MAY). 클라이언트가 "Authorization" 요청 헤더 필드를 통해 인증을 시도한 경우, 인가 서버는 HTTP 401 (Unauthorized) 상태 코드로 응답하고 클라이언트가 사용한 인증 스킴과 일치하는 "WWW-Authenticate" 응답 헤더 필드를 포함해야 한다(MUST). invalid_grant 제공된 인가 부여(예: 인가 코드, 리소스 소유자 자격 증명) 또는 갱신 토큰이 유효하지 않거나, 만료되었거나, 폐기되었거나, 인가 요청에 사용된 리디렉션 URI와 일치하지 않거나, 다른 클라이언트에 발급되었다. unauthorized_client 인증된 클라이언트가 이 인가 부여 유형을 사용할 권한이 없다. unsupported_grant_type 인가 서버가 인가 부여 유형을 지원하지 않는다. Hardt 표준 트랙 [Page 45]
RFC 6749 OAuth 2.0 2012년 10월 invalid_scope 요청된 scope가 유효하지 않거나, 알 수 없거나, 형식이 잘못되었거나, 리소스 소유자가 부여한 범위를 초과한다. "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_description OPTIONAL. 발생한 오류를 클라이언트 개발자가 이해하는 데 도움을 주기 위해 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII [USASCII] 텍스트이다. "error_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). error_uri OPTIONAL. 오류에 대한 정보가 있는 사람이 읽을 수 있는 웹 페이지를 식별하는 URI이며, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용된다. "error_uri" 매개변수의 값은 URI-reference 구문을 준수해야 하며(MUST), 따라서 %x21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). 매개변수는 [RFC4627]에 정의된 "application/json" 미디어 유형을 사용하여 HTTP 응답의 entity-body에 포함된다. 매개변수는 각 매개변수를 최상위 구조 수준에 추가함으로써 JSON 구조로 직렬화된다. 매개변수 이름과 문자열 값은 JSON 문자열로 포함된다. 숫자 값은 JSON 숫자로 포함된다. 매개변수의 순서는 중요하지 않으며 달라질 수 있다. 예: HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" } Hardt 표준 트랙 [Page 46]
RFC 6749 OAuth 2.0 2012년 10월 6. 접근 토큰 갱신 인가 서버가 클라이언트에 갱신 토큰을 발급한 경우, 클라이언트는 HTTP 요청 entity-body에서 UTF-8 문자 인코딩을 사용하고 Appendix B에 따른 "application/x-www-form-urlencoded" 형식으로 다음 매개변수를 추가하여 토큰 엔드포인트에 갱신 요청을 한다. grant_type REQUIRED. 값은 "refresh_token"으로 설정해야 한다(MUST). refresh_token REQUIRED. 클라이언트에 발급된 갱신 토큰이다. scope OPTIONAL. Section 3.3에 설명된 접근 요청의 범위이다. 요청된 scope는 리소스 소유자가 원래 부여하지 않은 scope를 포함해서는 안 되며(MUST NOT), 생략된 경우 리소스 소유자가 원래 부여한 scope와 동일한 것으로 처리된다. 갱신 토큰은 일반적으로 추가 접근 토큰을 요청하는 데 사용되는 장기 자격 증명이므로, 갱신 토큰은 그것이 발급된 클라이언트에 결합된다. 클라이언트 유형이 confidential이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우(또는 다른 인증 요구사항이 할당된 경우), 클라이언트는 Section 3.2.1에 설명된 대로 인가 서버에 인증해야 한다(MUST). 예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 한다(표시 목적으로만 추가 줄바꿈 사용). POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA Hardt 표준 트랙 [Page 47]
RFC 6749 OAuth 2.0 2012년 10월 인가 서버는 다음을 수행해야 한다(MUST). o confidential 클라이언트 또는 클라이언트 자격 증명을 발급받은 모든 클라이언트(또는 기타 인증 요구사항이 있는 클라이언트)에 대해 클라이언트 인증을 요구한다. o 클라이언트 인증이 포함된 경우 클라이언트를 인증하고, 갱신 토큰이 인증된 클라이언트에 발급되었음을 보장한다. 그리고 o 갱신 토큰을 검증한다. 유효하고 인가된 경우, 인가 서버는 Section 5.1에 설명된 대로 접근 토큰을 발급한다. 요청 검증이 실패했거나 유효하지 않은 경우, 인가 서버는 Section 5.2에 설명된 대로 오류 응답을 반환한다. 인가 서버는 새 갱신 토큰을 발급할 수 있으며(MAY), 이 경우 클라이언트는 이전 갱신 토큰을 폐기하고 새 갱신 토큰으로 교체해야 한다(MUST). 인가 서버는 클라이언트에 새 갱신 토큰을 발급한 후 이전 갱신 토큰을 폐기할 수 있다(MAY). 새 갱신 토큰이 발급되는 경우, 갱신 토큰 scope는 클라이언트가 요청에 포함한 갱신 토큰의 scope와 동일해야 한다(MUST). 7. 보호된 리소스 접근 클라이언트는 접근 토큰을 리소스 서버에 제시하여 보호된 리소스에 접근한다. 리소스 서버는 접근 토큰을 검증하고, 만료되지 않았으며 그 scope가 요청된 리소스를 포함하는지 보장해야 한다 (MUST). 리소스 서버가 접근 토큰을 검증하는 데 사용하는 방법 (및 모든 오류 응답)은 이 명세의 범위를 벗어나지만, 일반적으로 리소스 서버와 인가 서버 간의 상호작용 또는 조정을 포함한다. 클라이언트가 접근 토큰을 사용하여 리소스 서버에 인증하는 방법은 인가 서버가 발급한 접근 토큰 유형에 따라 달라진다. 일반적으로 이는 사용된 접근 토큰 유형의 명세에서 정의한 인증 스킴과 함께 HTTP "Authorization" 요청 헤더 필드 [RFC2617]를 사용하는 것을 포함한다. 예를 들면 [RFC6750]과 같다. Hardt 표준 트랙 [Page 48]
RFC 6749 OAuth 2.0 2012년 10월 7.1. 접근 토큰 유형 접근 토큰 유형은 클라이언트가 접근 토큰을 성공적으로 사용하여 보호된 리소스 요청을 하기 위해 필요한 정보(유형별 속성과 함께)를 제공한다. 클라이언트는 토큰 유형을 이해하지 못하는 경우 접근 토큰을 사용해서는 안 된다(MUST NOT). 예를 들어, [RFC6750]에 정의된 "bearer" 토큰 유형은 접근 토큰 문자열을 요청에 단순히 포함하여 사용한다. GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer mF_9.B5f-4.1JqM 반면 [OAuth-HTTP-MAC]에 정의된 "mac" 토큰 유형은 HTTP 요청의 특정 구성요소에 서명하는 데 사용되는 접근 토큰과 함께 Message Authentication Code (MAC) 키를 발급하여 사용한다. GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC id="h480djs93hd8", nonce="274312:dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" 위 예는 설명 목적으로만 제공된다. 개발자는 사용 전에 [RFC6750] 및 [OAuth-HTTP-MAC] 명세를 참조할 것을 권장한다. 각 접근 토큰 유형 정의는 "access_token" 응답 매개변수와 함께 클라이언트에 전송되는 추가 속성(있는 경우)을 지정한다. 또한 보호된 리소스 요청을 할 때 접근 토큰을 포함하는 데 사용되는 HTTP 인증 방법도 정의한다. 7.2. 오류 응답 리소스 접근 요청이 실패하면, 리소스 서버는 클라이언트에 오류를 알려야 한다(SHOULD). 그러한 오류 응답의 세부사항은 이 명세의 범위를 벗어나지만, 이 문서는 OAuth 토큰 인증 스킴 간에 공유할 오류 값을 위한 공통 레지스트리를 Section 11.4에 설정한다. 주로 OAuth 토큰 인증을 위해 설계된 새 인증 스킴은 클라이언트에 오류 상태 코드를 제공하는 메커니즘을 정의해야 하며(SHOULD), 허용되는 오류 값은 이 명세가 설정한 오류 레지스트리에 등록된다. Hardt 표준 트랙 [Page 49]
RFC 6749 OAuth 2.0 2012년 10월 이러한 스킴은 유효한 오류 코드 집합을 등록된 값의 하위 집합으로 제한할 수 있다(MAY). 오류 코드가 명명된 매개변수를 사용하여 반환되는 경우, 매개변수 이름은 "error"여야 한다(SHOULD). OAuth 토큰 인증에 사용할 수 있지만 주로 그 목적을 위해 설계되지는 않은 다른 스킴도 같은 방식으로 자신의 오류 값을 레지스트리에 결합할 수 있다(MAY). 새 인증 스킴은 이 명세에서의 사용과 병렬적인 방식으로 오류 정보를 반환하기 위해 "error_description" 및 "error_uri" 매개변수의 사용도 지정하도록 선택할 수 있다(MAY). 8. 확장성 8.1. 접근 토큰 유형 정의 접근 토큰 유형은 두 가지 방법 중 하나로 정의될 수 있다. Access Token Types 레지스트리에 등록하거나(Section 11.1의 절차를 따름), 고유한 절대 URI를 이름으로 사용하는 것이다. URI 이름을 사용하는 유형은 일반적으로 적용되지 않고, 사용되는 리소스 서버의 구현 세부사항에 특화된 벤더별 구현으로 제한되어야 한다(SHOULD). 다른 모든 유형은 등록되어야 한다(MUST). 유형 이름은 type-name ABNF를 준수해야 한다(MUST). 유형 정의가 새 HTTP 인증 스킴을 포함하는 경우, 유형 이름은 HTTP 인증 스킴 이름([RFC2617]에 정의됨)과 동일해야 한다(SHOULD). 토큰 유형 "example"은 예에서 사용하기 위해 예약되어 있다. type-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA 8.2. 새 엔드포인트 매개변수 정의 인가 엔드포인트 또는 토큰 엔드포인트와 함께 사용할 새 요청 또는 응답 매개변수는 Section 11.2의 절차에 따라 OAuth Parameters 레지스트리에 정의되고 등록된다. 매개변수 이름은 param-name ABNF를 준수해야 하며(MUST), 매개변수 값 구문은 잘 정의되어야 한다(MUST)(예: ABNF를 사용하거나 기존 매개변수 구문에 대한 참조 사용). param-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA Hardt 표준 트랙 [Page 50]
RFC 6749 OAuth 2.0 2012년 10월 일반적으로 적용되지 않고 사용되는 인가 서버의 구현 세부사항에 특화된 등록되지 않은 벤더별 매개변수 확장은 다른 등록 값과 충돌할 가능성이 낮은 벤더별 접두사(예: 'companyname_'으로 시작)를 사용해야 한다(SHOULD). 8.3. 새 인가 부여 유형 정의 새 인가 부여 유형은 "grant_type" 매개변수와 함께 사용할 고유한 절대 URI를 할당하여 정의할 수 있다. 확장 부여 유형에 추가 토큰 엔드포인트 매개변수가 필요한 경우, 이러한 매개변수는 Section 11.2에 설명된 대로 OAuth Parameters 레지스트리에 등록되어야 한다(MUST). 8.4. 새 인가 엔드포인트 응답 유형 정의 인가 엔드포인트와 함께 사용할 새 응답 유형은 Section 11.3의 절차에 따라 Authorization Endpoint Response Types 레지스트리에 정의되고 등록된다. 응답 유형 이름은 response-type ABNF를 준수해야 한다(MUST). response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = "_" / DIGIT / ALPHA 응답 유형이 하나 이상의 공백 문자(%x20)를 포함하는 경우, 값의 순서가 중요하지 않은 공백 구분 값 목록으로 비교된다. 값의 한 가지 순서만 등록될 수 있으며, 이는 같은 값 집합의 다른 모든 배열을 포괄한다. 예를 들어, 응답 유형 "token code"는 이 명세에서 정의되지 않은 채로 남겨져 있다. 그러나 확장은 "token code" 응답 유형을 정의하고 등록할 수 있다. 일단 등록되면 같은 조합을 "code token"으로 등록할 수 없지만, 두 값 모두 같은 응답 유형을 나타내는 데 사용할 수 있다. 8.5. 추가 오류 코드 정의 프로토콜 확장(즉, 접근 토큰 유형, 확장 매개변수 또는 확장 부여 유형)이 인가 코드 부여 오류 응답(Section 4.1.2.1), 암시적 부여 오류 응답(Section 4.2.2.1), 토큰 오류 응답 (Section 5.2), 또는 리소스 접근 오류 응답(Section 7.2)과 함께 사용할 추가 오류 코드를 필요로 하는 경우, 그러한 오류 코드는 정의될 수 있다(MAY). Hardt 표준 트랙 [Page 51]
RFC 6749 OAuth 2.0 2012년 10월 확장 오류 코드는 함께 사용되는 확장이 등록된 접근 토큰 유형, 등록된 엔드포인트 매개변수 또는 확장 부여 유형인 경우 등록되어야 한다(MUST)(Section 11.4의 절차를 따름). 등록되지 않은 확장과 함께 사용되는 오류 코드는 등록될 수 있다(MAY). 오류 코드는 error ABNF를 준수해야 하며(MUST), 가능한 경우 식별 이름이 접두사로 붙어야 한다(SHOULD). 예를 들어 확장 매개변수 "example"에 설정된 유효하지 않은 값을 식별하는 오류는 "example_invalid"로 명명되어야 한다(SHOULD). error = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E 9. 네이티브 애플리케이션 네이티브 애플리케이션은 리소스 소유자가 사용하는 장치에 설치되어 실행되는 클라이언트이다(즉, 데스크톱 애플리케이션, 네이티브 모바일 애플리케이션). 네이티브 애플리케이션은 보안, 플랫폼 기능, 전체 최종 사용자 경험과 관련된 특별한 고려가 필요하다. 인가 엔드포인트는 클라이언트와 리소스 소유자의 사용자 에이전트 간의 상호작용을 요구한다. 네이티브 애플리케이션은 외부 사용자 에이전트를 호출하거나 애플리케이션 안에 사용자 에이전트를 내장할 수 있다. 예를 들면 다음과 같다. o 외부 사용자 에이전트 - 네이티브 애플리케이션은 운영 체제에 등록되어 클라이언트를 handler로 호출하는 scheme을 가진 리디렉션 URI, 자격 증명의 수동 복사 및 붙여넣기, 로컬 웹 서버 실행, 사용자 에이전트 확장 설치, 또는 클라이언트의 제어 하에 있는 서버 호스팅 리소스를 식별하는 리디렉션 URI를 제공하는 방법을 사용하여 인가 서버의 응답을 캡처할 수 있다. 이 서버 호스팅 리소스는 다시 그 응답을 네이티브 애플리케이션에 사용할 수 있게 한다. o 내장 사용자 에이전트 - 네이티브 애플리케이션은 리소스 로드 중에 발생하는 상태 변화를 모니터링하거나 사용자 에이전트의 쿠키 저장소에 접근함으로써, 내장 사용자 에이전트와 직접 통신하여 응답을 얻는다. 외부 사용자 에이전트와 내장 사용자 에이전트 중에서 선택할 때, 개발자는 다음을 고려해야 한다. o 외부 사용자 에이전트는 리소스 소유자가 이미 인가 서버와 활성 세션을 가지고 있을 수 있으므로 완료율을 향상시킬 수 있으며, 재인증의 필요를 제거한다. 이는 익숙한 최종 사용자 경험과 기능을 제공한다. 리소스 소유자는 인증을 돕기 위해 Hardt 표준 트랙 [Page 52]
RFC 6749 OAuth 2.0 2012년 10월 사용자 에이전트 기능이나 확장(예: 비밀번호 관리자, 2단계 장치 리더)에 의존할 수도 있다. o 내장 사용자 에이전트는 컨텍스트 전환과 새 창 열기의 필요를 제거하므로 향상된 사용성을 제공할 수 있다. o 내장 사용자 에이전트는 보안 문제를 제기한다. 리소스 소유자가 대부분의 외부 사용자 에이전트에서 제공되는 시각적 보호 장치에 접근할 수 없는 식별되지 않은 창에서 인증하기 때문이다. 내장 사용자 에이전트는 최종 사용자가 식별되지 않은 인증 요청을 신뢰하도록 학습시킨다(피싱 공격을 실행하기 쉽게 만든다). 암시적 부여 유형과 인가 코드 부여 유형 중에서 선택할 때, 다음을 고려해야 한다. o 인가 코드 부여 유형을 사용하는 네이티브 애플리케이션은 네이티브 애플리케이션이 클라이언트 자격 증명을 기밀로 유지할 수 없기 때문에 클라이언트 자격 증명 없이 그렇게 해야 한다(SHOULD). o 암시적 부여 유형 흐름을 사용할 때는 갱신 토큰이 반환되지 않으므로, 접근 토큰이 만료되면 인가 과정을 반복해야 한다. 10. 보안 고려사항 유연하고 확장 가능한 프레임워크로서, OAuth의 보안 고려사항은 여러 요인에 의존한다. 다음 절들은 Section 2.1에 설명된 세 클라이언트 프로파일, 즉 web application, user-agent-based application, native application에 초점을 맞춘 보안 지침을 구현자에게 제공한다. 포괄적인 OAuth 보안 모델과 분석, 그리고 프로토콜 설계 배경은 [OAuth-THREATMODEL]에서 제공된다. 10.1. 클라이언트 인증 인가 서버는 클라이언트 인증을 목적으로 웹 애플리케이션 클라이언트와 클라이언트 자격 증명을 설정한다. 인가 서버는 클라이언트 비밀번호보다 더 강한 클라이언트 인증 수단을 고려할 것이 권장된다. 웹 애플리케이션 클라이언트는 클라이언트 비밀번호 및 기타 클라이언트 자격 증명의 기밀성을 보장해야 한다(MUST). Hardt 표준 트랙 [Page 53]
RFC 6749 OAuth 2.0 2012년 10월 인가 서버는 클라이언트 인증을 목적으로 네이티브 애플리케이션 또는 사용자 에이전트 기반 애플리케이션 클라이언트에 클라이언트 비밀번호나 기타 클라이언트 자격 증명을 발급해서는 안 된다 (MUST NOT). 인가 서버는 특정 장치의 네이티브 애플리케이션 클라이언트의 특정 설치에 대해 클라이언트 비밀번호나 기타 자격 증명을 발급할 수 있다(MAY). 클라이언트 인증이 불가능한 경우, 인가 서버는 클라이언트의 신원을 검증하기 위해 다른 수단을 사용해야 한다(SHOULD). 예를 들어 클라이언트 리디렉션 URI의 등록을 요구하거나 리소스 소유자에게 신원 확인을 요청하는 것이다. 유효한 리디렉션 URI는 리소스 소유자 인가를 요청할 때 클라이언트 신원을 검증하기에 충분하지 않지만, 리소스 소유자 인가를 얻은 후 위조 클라이언트에 자격 증명이 전달되는 것을 방지하는 데 사용할 수 있다. 인가 서버는 인증되지 않은 클라이언트와 상호작용하는 보안 영향을 고려하고, 그러한 클라이언트에 발급되는 기타 자격 증명 (예: 갱신 토큰)의 잠재적 노출을 제한하기 위한 조치를 취해야 한다. 10.2. 클라이언트 사칭 악의적인 클라이언트는 사칭 대상 클라이언트가 클라이언트 자격 증명을 기밀로 유지하지 못하거나 유지할 수 없는 경우, 다른 클라이언트를 사칭하여 보호된 리소스에 대한 접근을 얻을 수 있다. 인가 서버는 가능할 때마다 클라이언트를 인증해야 한다(MUST). 인가 서버가 클라이언트의 특성 때문에 클라이언트를 인증할 수 없는 경우, 인가 서버는 인가 응답을 수신하는 데 사용되는 모든 리디렉션 URI의 등록을 요구해야 하며(MUST), 그러한 잠재적으로 악의적인 클라이언트로부터 리소스 소유자를 보호하기 위해 다른 수단을 활용해야 한다(SHOULD). 예를 들어, 인가 서버는 리소스 소유자가 클라이언트와 그 출처를 식별하도록 참여시킬 수 있다. 인가 서버는 명시적인 리소스 소유자 인증을 강제하고, 리소스 소유자에게 클라이언트와 요청된 인가 scope 및 수명에 대한 정보를 제공해야 한다(SHOULD). 현재 클라이언트의 맥락에서 정보를 검토하고 요청을 승인하거나 거부하는 것은 리소스 소유자에게 달려 있다. 인가 서버는 클라이언트를 인증하거나 반복 요청이 사칭자가 아닌 원래 클라이언트에서 온 것임을 보장하기 위한 다른 조치에 의존하지 않고는, 반복되는 인가 요청을 자동으로(리소스 소유자의 적극적 상호작용 없이) 처리해서는 안 된다(SHOULD NOT). Hardt 표준 트랙 [Page 54]
RFC 6749 OAuth 2.0 2012년 10월 10.3. 접근 토큰 접근 토큰 자격 증명(및 모든 기밀 접근 토큰 속성)은 전송 중과 저장 중에 기밀로 유지되어야 하며(MUST), 인가 서버, 접근 토큰이 유효한 리소스 서버들, 그리고 접근 토큰이 발급된 클라이언트 사이에서만 공유되어야 한다. 접근 토큰 자격 증명은 Section 1.6에 설명된 TLS를 사용하고 [RFC2818]에 정의된 서버 인증과 함께 전송되어야 한다(MUST). 암시적 부여 유형을 사용할 때, 접근 토큰은 URI 프래그먼트로 전송되며, 이는 권한 없는 당사자에게 노출될 수 있다. 인가 서버는 접근 토큰이 권한 없는 당사자에 의해 유효한 접근 토큰으로 생성, 수정 또는 추측될 수 없도록 보장해야 한다 (MUST). 클라이언트는 필요한 최소 scope로 접근 토큰을 요청해야 한다 (SHOULD). 인가 서버는 요청된 scope를 어떻게 승인할지 선택할 때 클라이언트 신원을 고려해야 하며(SHOULD), 요청보다 적은 권한을 가진 접근 토큰을 발급할 수 있다(MAY). 이 명세는 리소스 서버가 특정 클라이언트가 제시한 접근 토큰이 인가 서버에 의해 그 클라이언트에 발급되었음을 보장하는 방법을 제공하지 않는다. 10.4. 갱신 토큰 인가 서버는 웹 애플리케이션 클라이언트와 네이티브 애플리케이션 클라이언트에 갱신 토큰을 발급할 수 있다(MAY). 갱신 토큰은 전송 중과 저장 중에 기밀로 유지되어야 하며(MUST), 인가 서버와 갱신 토큰이 발급된 클라이언트 사이에서만 공유되어야 한다. 인가 서버는 갱신 토큰과 그것이 발급된 클라이언트 사이의 결합을 유지해야 한다(MUST). 갱신 토큰은 Section 1.6에 설명된 TLS를 사용하고 [RFC2818]에 정의된 서버 인증과 함께 전송되어야 한다(MUST). 인가 서버는 클라이언트 신원을 인증할 수 있을 때마다 갱신 토큰과 클라이언트 신원 사이의 결합을 검증해야 한다(MUST). 클라이언트 인증이 불가능한 경우, 인가 서버는 갱신 토큰 남용을 탐지하기 위해 다른 수단을 배포해야 한다(SHOULD). 예를 들어, 인가 서버는 모든 접근 토큰 갱신 응답마다 새 갱신 토큰을 발급하는 갱신 토큰 회전을 사용할 수 있다. 이전 갱신 토큰은 무효화되지만 Hardt 표준 트랙 [Page 55]
RFC 6749 OAuth 2.0 2012년 10월 인가 서버에 보관된다. 갱신 토큰이 침해된 뒤 공격자와 합법적인 클라이언트가 모두 이를 사용하는 경우, 그중 하나는 무효화된 갱신 토큰을 제시하게 되며, 이는 인가 서버에 침해 사실을 알린다. 인가 서버는 갱신 토큰이 권한 없는 당사자에 의해 유효한 갱신 토큰으로 생성, 수정 또는 추측될 수 없도록 보장해야 한다(MUST). 10.5. 인가 코드 인가 코드의 전송은 보안 채널을 통해 이루어져야 하며(SHOULD), URI가 네트워크 리소스를 식별하는 경우 클라이언트는 자신의 리디렉션 URI에 TLS 사용을 요구해야 한다(SHOULD). 인가 코드는 사용자 에이전트 리디렉션을 통해 전송되므로, 사용자 에이전트 기록과 HTTP referrer 헤더를 통해 잠재적으로 공개될 수 있다. 인가 코드는 평문 bearer 자격 증명으로 동작하며, 인가 서버에서 인가를 부여한 리소스 소유자가 과정을 완료하기 위해 클라이언트로 돌아오는 동일한 리소스 소유자인지 검증하는 데 사용된다. 따라서 클라이언트가 자체 리소스 소유자 인증을 위해 인가 코드에 의존하는 경우, 클라이언트 리디렉션 엔드포인트는 TLS 사용을 요구해야 한다 (MUST). 인가 코드는 수명이 짧고 단일 사용이어야 한다(MUST). 인가 서버가 인가 코드를 접근 토큰으로 교환하려는 여러 시도를 관찰하는 경우, 인가 서버는 침해된 인가 코드를 기반으로 이미 부여된 모든 접근 토큰을 폐기하려고 시도해야 한다(SHOULD). 클라이언트를 인증할 수 있는 경우, 인가 서버는 클라이언트를 인증하고 인가 코드가 같은 클라이언트에 발급되었음을 보장해야 한다(MUST). 10.6. 인가 코드 리디렉션 URI 조작 인가 코드 부여 유형을 사용하여 인가를 요청할 때, 클라이언트는 "redirect_uri" 매개변수를 통해 리디렉션 URI를 지정할 수 있다. 공격자가 리디렉션 URI 값을 조작할 수 있으면, 인가 서버가 리소스 소유자 사용자 에이전트를 공격자가 제어하는 URI로 인가 코드와 함께 리디렉션하게 만들 수 있다. 공격자는 합법적인 클라이언트에 계정을 만들고 인가 흐름을 시작할 수 있다. 공격자의 사용자 에이전트가 접근을 허가하기 위해 인가 서버로 보내지면, 공격자는 합법적인 클라이언트가 제공한 인가 URI를 가져와 Hardt 표준 트랙 [Page 56]
RFC 6749 OAuth 2.0 2012년 10월 클라이언트의 리디렉션 URI를 공격자가 제어하는 URI로 바꾼다. 그런 다음 공격자는 피해자가 조작된 링크를 따라가 합법적인 클라이언트에 대한 접근을 인가하도록 속인다. 인가 서버에 도달하면 피해자는 합법적이고 신뢰할 수 있는 클라이언트를 대신한 정상적이고 유효한 요청을 보게 되며, 요청을 인가한다. 그러면 피해자는 인가 코드와 함께 공격자가 제어하는 엔드포인트로 리디렉션된다. 공격자는 클라이언트가 제공한 원래 리디렉션 URI를 사용하여 인가 코드를 클라이언트에 보내 인가 흐름을 완료한다. 클라이언트는 인가 코드를 접근 토큰으로 교환하고 이를 공격자의 클라이언트 계정에 연결한다. 이 계정은 이제 피해자가 인가한 보호된 리소스에 (클라이언트를 통해) 접근할 수 있다. 이러한 공격을 방지하기 위해, 인가 서버는 인가 코드를 얻는 데 사용된 리디렉션 URI가 인가 코드를 접근 토큰으로 교환할 때 제공된 리디렉션 URI와 동일함을 보장해야 한다(MUST). 인가 서버는 public 클라이언트가 리디렉션 URI를 등록하도록 요구해야 하며 (MUST), confidential 클라이언트에도 등록을 요구해야 한다(SHOULD). 요청에 리디렉션 URI가 제공된 경우, 인가 서버는 등록된 값에 대해 이를 검증해야 한다(MUST). 10.7. 리소스 소유자 비밀번호 자격 증명 리소스 소유자 비밀번호 자격 증명 부여 유형은 종종 레거시 또는 마이그레이션 이유로 사용된다. 이는 클라이언트가 사용자 이름과 비밀번호를 저장하는 전체 위험을 줄이지만, 높은 권한의 자격 증명을 클라이언트에 노출해야 하는 필요를 제거하지는 않는다. 이 부여 유형은 이 프로토콜이 피하려는 비밀번호 안티패턴을 유지하므로 다른 부여 유형보다 더 높은 위험을 수반한다. 클라이언트가 비밀번호를 남용할 수 있으며, 비밀번호가 공격자에게 의도치 않게 공개될 수 있다(예: 클라이언트가 보관하는 로그 파일 또는 기타 기록을 통해). 또한 리소스 소유자는 인가 과정을 제어하지 못하므로(리소스 소유자의 관여는 클라이언트에 자격 증명을 넘겨줄 때 끝남), 클라이언트는 리소스 소유자가 원하는 것보다 더 넓은 scope의 접근 토큰을 얻을 수 있다. 인가 서버는 이 부여 유형을 통해 발급되는 접근 토큰의 scope와 수명을 고려해야 한다. 인가 서버와 클라이언트는 이 부여 유형의 사용을 최소화하고, 가능한 경우 다른 부여 유형을 활용해야 한다(SHOULD). Hardt 표준 트랙 [Page 57]
RFC 6749 OAuth 2.0 2012년 10월 10.8. 요청 기밀성 접근 토큰, 갱신 토큰, 리소스 소유자 비밀번호, 클라이언트 자격 증명은 평문으로 전송되어서는 안 된다(MUST NOT). 인가 코드는 평문으로 전송되지 않아야 한다(SHOULD NOT). "state" 및 "scope" 매개변수는 민감한 클라이언트 또는 리소스 소유자 정보를 평문으로 포함해서는 안 된다(SHOULD NOT). 이는 안전하지 않은 채널을 통해 전송되거나 안전하지 않게 저장될 수 있기 때문이다. 10.9. 엔드포인트 진정성 보장 중간자 공격을 방지하기 위해, 인가 서버는 인가 엔드포인트와 토큰 엔드포인트로 전송되는 모든 요청에 대해 [RFC2818]에 정의된 서버 인증과 함께 TLS 사용을 요구해야 한다(MUST). 클라이언트는 [RFC6125]에 정의된 대로, 그리고 서버 신원 인증에 대한 자신의 요구사항에 따라 인가 서버의 TLS 인증서를 검증해야 한다(MUST). 10.10. 자격 증명 추측 공격 인가 서버는 공격자가 접근 토큰, 인가 코드, 갱신 토큰, 리소스 소유자 비밀번호, 클라이언트 자격 증명을 추측하지 못하게 해야 한다(MUST). 공격자가 생성된 토큰(및 최종 사용자가 처리하도록 의도되지 않은 기타 자격 증명)을 추측할 확률은 2^(-128) 이하여야 하며(MUST), 2^(-160) 이하이어야 한다(SHOULD). 인가 서버는 최종 사용자 사용을 의도한 자격 증명을 보호하기 위해 다른 수단을 활용해야 한다(MUST). 10.11. 피싱 공격 이 프로토콜 및 유사한 프로토콜의 광범위한 배포는 최종 사용자가 비밀번호 입력을 요구받는 웹 사이트로 리디렉션되는 관행에 무감각해지게 만들 수 있다. 최종 사용자가 자격 증명을 입력하기 전에 이러한 웹 사이트의 진정성을 신중하게 확인하지 않으면, 공격자는 이 관행을 악용하여 리소스 소유자의 비밀번호를 훔칠 수 있다. 서비스 제공자는 피싱 공격이 초래하는 위험에 대해 최종 사용자를 교육하려고 노력해야 하며, 최종 사용자가 사이트의 진정성을 쉽게 확인할 수 있는 메커니즘을 제공해야 한다. 클라이언트 개발자는 사용자 에이전트(예: 외부, 내장)와 상호작용하는 방식의 보안 영향과, 최종 사용자가 인가 서버의 진정성을 검증할 수 있는 능력을 고려해야 한다. Hardt 표준 트랙 [Page 58]
RFC 6749 OAuth 2.0 2012년 10월 피싱 공격 위험을 줄이기 위해, 인가 서버는 최종 사용자 상호작용에 사용되는 모든 엔드포인트에서 TLS 사용을 요구해야 한다(MUST). 10.12. 사이트 간 요청 위조 사이트 간 요청 위조(CSRF)는 공격자가 피해 최종 사용자의 사용자 에이전트가 악의적인 URI(예: 오해를 유도하는 링크, 이미지 또는 리디렉션으로 사용자 에이전트에 제공됨)를 신뢰하는 서버(일반적으로 유효한 세션 쿠키의 존재로 설정됨)로 따라가게 하는 공격이다. 클라이언트의 리디렉션 URI에 대한 CSRF 공격은 공격자가 자신의 인가 코드 또는 접근 토큰을 주입할 수 있게 하며, 그 결과 클라이언트가 피해자의 보호된 리소스가 아니라 공격자의 보호된 리소스와 연결된 접근 토큰을 사용하게 될 수 있다(예: 피해자의 은행 계좌 정보를 공격자가 제어하는 보호된 리소스에 저장). 클라이언트는 자신의 리디렉션 URI에 대해 CSRF 보호를 구현해야 한다(MUST). 이는 일반적으로 리디렉션 URI 엔드포인트로 전송되는 모든 요청에 사용자 에이전트의 인증된 상태에 요청을 결합하는 값(예: 사용자 에이전트를 인증하는 데 사용된 세션 쿠키의 해시)을 포함하도록 요구함으로써 달성된다. 클라이언트는 인가 요청을 할 때 이 값을 인가 서버에 전달하기 위해 "state" 요청 매개변수를 활용해야 한다(SHOULD). 최종 사용자로부터 인가를 얻으면, 인가 서버는 "state" 매개변수 안에 필요한 결합 값을 포함하여 최종 사용자의 사용자 에이전트를 다시 클라이언트로 리디렉션한다. 결합 값은 클라이언트가 그 값을 사용자 에이전트의 인증된 상태와 일치시켜 요청의 유효성을 검증할 수 있게 한다. CSRF 보호에 사용되는 결합 값은 Section 10.10에 설명된 것처럼 추측할 수 없는 값을 포함해야 하며(MUST), 사용자 에이전트의 인증된 상태(예: 세션 쿠키, HTML5 local storage)는 클라이언트와 사용자 에이전트만 접근할 수 있는 위치 (즉, same-origin policy로 보호됨)에 보관되어야 한다(MUST). 인가 서버의 인가 엔드포인트에 대한 CSRF 공격은 공격자가 최종 사용자를 개입시키거나 경고하지 않고 악의적인 클라이언트에 대한 최종 사용자 인가를 얻는 결과를 초래할 수 있다. 인가 서버는 자신의 인가 엔드포인트에 대해 CSRF 보호를 구현하고, 악의적인 클라이언트가 리소스 소유자의 인식과 명시적 동의 없이 인가를 얻을 수 없도록 보장해야 한다(MUST). Hardt 표준 트랙 [Page 59]
RFC 6749 OAuth 2.0 2012년 10월 10.13. 클릭재킹 클릭재킹 공격에서, 공격자는 합법적인 클라이언트를 등록한 다음, 인가 서버의 인가 엔드포인트 웹 페이지를 투명한 iframe 안에 로드하고 이를 더미 버튼 집합 위에 겹쳐 놓는 악의적인 사이트를 구성한다. 이 더미 버튼들은 인가 페이지의 중요한 버튼 바로 아래에 위치하도록 신중하게 구성된다. 최종 사용자가 오해를 유도하는 보이는 버튼을 클릭하면, 실제로는 인가 페이지의 보이지 않는 버튼(예: "Authorize" 버튼)을 클릭하는 것이다. 이를 통해 공격자는 리소스 소유자를 속여 최종 사용자가 알지 못하는 사이에 자신의 클라이언트에 접근 권한을 부여하게 할 수 있다. 이러한 형태의 공격을 방지하기 위해, 네이티브 애플리케이션은 최종 사용자 인가를 요청할 때 애플리케이션 안에 브라우저를 내장하는 대신 외부 브라우저를 사용해야 한다(SHOULD). 대부분의 최신 브라우저에서는 인가 서버가 (비표준) "x-frame-options" 헤더를 사용하여 iframe 회피를 강제할 수 있다. 이 헤더는 "deny"와 "sameorigin" 두 값을 가질 수 있으며, 각각 모든 프레이밍 또는 다른 origin을 가진 사이트에 의한 프레이밍을 차단한다. 오래된 브라우저의 경우 JavaScript frame-busting 기법을 사용할 수 있지만, 모든 브라우저에서 효과적이지 않을 수 있다. 10.14. 코드 주입 및 입력 검증 코드 주입 공격은 입력 또는 기타 외부 변수가 애플리케이션에서 정제되지 않은 채 사용되어 애플리케이션 로직의 변경을 유발할 때 발생한다. 이는 공격자가 애플리케이션 장치나 그 데이터에 접근할 수 있게 하거나, 서비스 거부를 일으키거나, 광범위한 악의적 부작용을 도입하게 할 수 있다. 인가 서버와 클라이언트는 수신한 모든 값, 특히 "state" 및 "redirect_uri" 매개변수 값을 정제해야 하며(가능한 경우 검증해야 한다)(MUST). 10.15. 오픈 리디렉터 인가 서버, 인가 엔드포인트, 클라이언트 리디렉션 엔드포인트는 잘못 구성되어 오픈 리디렉터로 동작할 수 있다. 오픈 리디렉터는 매개변수를 사용하여 아무 검증 없이 사용자 에이전트를 매개변수 값이 지정한 위치로 자동 리디렉션하는 엔드포인트이다. 오픈 리디렉터는 피싱 공격에 사용될 수 있고, 익숙하고 신뢰할 수 있는 목적지의 URI authority 구성요소를 사용하여 최종 사용자가 악의적인 사이트를 방문하게 만드는 데 공격자가 사용할 수도 있다. 또한 인가 서버가 클라이언트가 리디렉션 URI의 일부만 등록하도록 허용하는 경우, 공격자는 클라이언트가 운영하는 오픈 리디렉터를 Hardt 표준 트랙 [Page 60]
RFC 6749 OAuth 2.0 2012년 10월 사용하여 인가 서버 검증은 통과하지만 인가 코드나 접근 토큰을 공격자가 제어하는 엔드포인트로 보내는 리디렉션 URI를 구성할 수 있다. 10.16. 암시적 흐름에서 리소스 소유자를 사칭하기 위한 접근 토큰의 오용 흐름 암시적 흐름을 사용하는 public 클라이언트의 경우, 이 명세는 접근 토큰이 어떤 클라이언트에 발급되었는지 클라이언트가 판단할 수 있는 어떤 방법도 제공하지 않는다. 리소스 소유자는 공격자의 악의적인 클라이언트에 접근 토큰을 부여함으로써 리소스에 대한 접근을 자발적으로 위임할 수 있다. 이는 피싱 또는 다른 구실 때문일 수 있다. 공격자는 다른 메커니즘을 통해 토큰을 훔칠 수도 있다. 그런 다음 공격자는 접근 토큰을 합법적인 public 클라이언트에 제공하여 리소스 소유자를 사칭하려고 시도할 수 있다. 암시적 흐름(response_type=token)에서, 공격자는 인가 서버의 응답에 있는 토큰을 쉽게 바꾸어, 실제 접근 토큰을 공격자에게 이전에 발급된 토큰으로 대체할 수 있다. 클라이언트의 사용자를 식별하기 위해 백 채널에서 접근 토큰을 전달받는 것에 의존하는 네이티브 애플리케이션과 통신하는 서버도, 임의의 도난 접근 토큰을 주입할 수 있는 침해된 애플리케이션을 공격자가 생성함으로써 유사하게 침해될 수 있다. 리소스에 대한 유효한 접근 토큰을 자신에게 제시할 수 있는 것은 리소스 소유자뿐이라고 가정하는 모든 public 클라이언트는 이러한 유형의 공격에 취약하다. 이러한 유형의 공격은 합법적인 클라이언트에서 리소스 소유자에 대한 정보를 공격자(악의적인 클라이언트)에게 노출할 수 있다. 또한 공격자가 원래 접근 토큰 또는 인가 코드를 부여한 리소스 소유자와 같은 권한으로 합법적인 클라이언트에서 작업을 수행할 수 있게 한다. 클라이언트에 리소스 소유자를 인증하는 것은 이 명세의 범위를 벗어난다. 인가 과정을 클라이언트에 대한 위임된 최종 사용자 인증의 한 형태(예: 서드파티 로그인 서비스)로 사용하는 모든 명세는, 접근 토큰이 해당 클라이언트의 사용을 위해 발급되었는지 클라이언트가 판단할 수 있게 하는 추가 보안 메커니즘(예: 접근 토큰의 audience 제한) 없이 암시적 흐름을 사용해서는 안 된다 (MUST NOT). Hardt 표준 트랙 [Page 61]
RFC 6749 OAuth 2.0 2012년 10월 11. IANA 고려사항 11.1. OAuth 접근 토큰 유형 레지스트리 이 명세는 OAuth Access Token Types 레지스트리를 설정한다. 접근 토큰 유형은 하나 이상의 Designated Expert의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주 검토 기간을 거친 후 Specification Required([RFC5226])로 등록된다. 다만 출판 전에 값 할당을 허용하기 위해, Designated Expert(들)는 그러한 명세가 출판될 것이라고 만족하면 등록을 승인할 수 있다. 등록 요청은 검토와 의견 수렴을 위해 적절한 제목(예: "Request for access token type: example")과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 한다. 검토 기간 내에 Designated Expert(들)는 등록 요청을 승인하거나 거부하고, 그 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명과, 해당되는 경우 요청이 성공할 수 있도록 하는 제안이 포함되어야 한다. IANA는 Designated Expert(들)로부터의 레지스트리 업데이트만 수락해야 하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다. 11.1.1. 등록 템플릿 Type name: 요청된 이름(예: "example"). Additional Token Endpoint Response Parameters: "access_token" 매개변수와 함께 반환되는 추가 응답 매개변수. 새 매개변수는 Section 11.2에 설명된 대로 OAuth Parameters 레지스트리에 별도로 등록되어야 한다(MUST). HTTP Authentication Scheme(s): 이 유형의 접근 토큰을 사용하여 보호된 리소스 요청을 인증하는 데 사용되는 HTTP 인증 스킴 이름(있는 경우). Change controller: Standards Track RFC의 경우 "IETF"라고 명시한다. 그 밖의 경우 책임 당사자의 이름을 제공한다. 기타 세부사항(예: 우편 주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다. Hardt 표준 트랙 [Page 62]
RFC 6749 OAuth 2.0 2012년 10월 Specification document(s): 매개변수를 지정하는 문서에 대한 참조이며, 가급적 문서의 사본을 검색하는 데 사용할 수 있는 URI를 포함한다. 관련 절의 표시도 포함될 수 있지만 필수는 아니다. 11.2. OAuth 매개변수 레지스트리 이 명세는 OAuth Parameters 레지스트리를 설정한다. 인가 엔드포인트 요청, 인가 엔드포인트 응답, 토큰 엔드포인트 요청 또는 토큰 엔드포인트 응답에 포함될 추가 매개변수는 하나 이상의 Designated Expert의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주 검토 기간을 거친 후 Specification Required([RFC5226])로 등록된다. 다만 출판 전에 값 할당을 허용하기 위해, Designated Expert(들)는 그러한 명세가 출판될 것이라고 만족하면 등록을 승인할 수 있다. 등록 요청은 검토와 의견 수렴을 위해 적절한 제목(예: "Request for parameter: example")과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 한다. 검토 기간 내에 Designated Expert(들)는 등록 요청을 승인하거나 거부하고, 그 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명과, 해당되는 경우 요청이 성공할 수 있도록 하는 제안이 포함되어야 한다. IANA는 Designated Expert(들)로부터의 레지스트리 업데이트만 수락해야 하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다. 11.2.1. 등록 템플릿 Parameter name: 요청된 이름(예: "example"). Parameter usage location: 매개변수를 사용할 수 있는 위치. 가능한 위치는 authorization request, authorization response, token request, token response이다. Change controller: Standards Track RFC의 경우 "IETF"라고 명시한다. 그 밖의 경우 책임 당사자의 이름을 제공한다. 기타 세부사항(예: 우편 주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다. Hardt 표준 트랙 [Page 63]
RFC 6749 OAuth 2.0 2012년 10월 Specification document(s): 매개변수를 지정하는 문서에 대한 참조이며, 가급적 문서의 사본을 검색하는 데 사용할 수 있는 URI를 포함한다. 관련 절의 표시도 포함될 수 있지만 필수는 아니다. 11.2.2. 초기 레지스트리 내용 OAuth Parameters 레지스트리의 초기 내용은 다음과 같다. o Parameter name: client_id o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: client_secret o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: response_type o Parameter usage location: authorization request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: redirect_uri o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: scope o Parameter usage location: authorization request, authorization response, token request, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: state o Parameter usage location: authorization request, authorization response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: code o Parameter usage location: authorization response, token request o Change controller: IETF o Specification document(s): RFC 6749 Hardt 표준 트랙 [Page 64]
RFC 6749 OAuth 2.0 2012년 10월 o Parameter name: error_description o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: error_uri o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: grant_type o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: access_token o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: token_type o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: expires_in o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: username o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: password o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749 o Parameter name: refresh_token o Parameter usage location: token request, token response o Change controller: IETF o Specification document(s): RFC 6749 Hardt 표준 트랙 [Page 65]
RFC 6749 OAuth 2.0 2012년 10월 11.3. OAuth 인가 엔드포인트 응답 유형 레지스트리 이 명세는 OAuth Authorization Endpoint Response Types 레지스트리를 설정한다. 인가 엔드포인트와 함께 사용할 추가 응답 유형은 하나 이상의 Designated Expert의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주 검토 기간을 거친 후 Specification Required([RFC5226])로 등록된다. 다만 출판 전에 값 할당을 허용하기 위해, Designated Expert(들)는 그러한 명세가 출판될 것이라고 만족하면 등록을 승인할 수 있다. 등록 요청은 검토와 의견 수렴을 위해 적절한 제목(예: "Request for response type: example")과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 한다. 검토 기간 내에 Designated Expert(들)는 등록 요청을 승인하거나 거부하고, 그 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명과, 해당되는 경우 요청이 성공할 수 있도록 하는 제안이 포함되어야 한다. IANA는 Designated Expert(들)로부터의 레지스트리 업데이트만 수락해야 하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다. 11.3.1. 등록 템플릿 Response type name: 요청된 이름(예: "example"). Change controller: Standards Track RFC의 경우 "IETF"라고 명시한다. 그 밖의 경우 책임 당사자의 이름을 제공한다. 기타 세부사항(예: 우편 주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다. Specification document(s): 유형을 지정하는 문서에 대한 참조이며, 가급적 문서의 사본을 검색하는 데 사용할 수 있는 URI를 포함한다. 관련 절의 표시도 포함될 수 있지만 필수는 아니다. Hardt 표준 트랙 [Page 66]
RFC 6749 OAuth 2.0 2012년 10월 11.3.2. 초기 레지스트리 내용 OAuth Authorization Endpoint Response Types 레지스트리의 초기 내용은 다음과 같다. o Response type name: code o Change controller: IETF o Specification document(s): RFC 6749 o Response type name: token o Change controller: IETF o Specification document(s): RFC 6749 11.4. OAuth 확장 오류 레지스트리 이 명세는 OAuth Extensions Error 레지스트리를 설정한다. 다른 프로토콜 확장(즉, 확장 부여 유형, 접근 토큰 유형 또는 확장 매개변수)과 함께 사용되는 추가 오류 코드는 하나 이상의 Designated Expert의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주 검토 기간을 거친 후 Specification Required([RFC5226])로 등록된다. 다만 출판 전에 값 할당을 허용하기 위해, Designated Expert(들)는 그러한 명세가 출판될 것이라고 만족하면 등록을 승인할 수 있다. 등록 요청은 검토와 의견 수렴을 위해 적절한 제목(예: "Request for error code: example")과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 한다. 검토 기간 내에 Designated Expert(들)는 등록 요청을 승인하거나 거부하고, 그 결정을 검토 리스트와 IANA에 전달한다. 거부에는 설명과, 해당되는 경우 요청이 성공할 수 있도록 하는 제안이 포함되어야 한다. IANA는 Designated Expert(들)로부터의 레지스트리 업데이트만 수락해야 하며, 모든 등록 요청을 검토 메일링 리스트로 안내해야 한다. Hardt 표준 트랙 [Page 67]
RFC 6749 OAuth 2.0 2012년 10월 11.4.1. 등록 템플릿 Error name: 요청된 이름(예: "example"). 오류 이름의 값은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 된다(MUST NOT). Error usage location: 오류를 사용할 수 있는 위치. 가능한 위치는 authorization code grant error response(Section 4.1.2.1), implicit grant error response(Section 4.2.2.1), token error response(Section 5.2), 또는 resource access error response(Section 7.2)이다. Related protocol extension: 오류 코드가 함께 사용되는 확장 부여 유형, 접근 토큰 유형 또는 확장 매개변수의 이름. Change controller: Standards Track RFC의 경우 "IETF"라고 명시한다. 그 밖의 경우 책임 당사자의 이름을 제공한다. 기타 세부사항(예: 우편 주소, 이메일 주소, 홈페이지 URI)도 포함될 수 있다. Specification document(s): 오류 코드를 지정하는 문서에 대한 참조이며, 가급적 문서의 사본을 검색하는 데 사용할 수 있는 URI를 포함한다. 관련 절의 표시도 포함될 수 있지만 필수는 아니다. 12. 참고문헌 12.1. 규범적 참고문헌 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997년 3월. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 1999년 1월. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, 1999년 6월. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, 1999년 6월. Hardt 표준 트랙 [Page 68]
RFC 6749 OAuth 2.0 2012년 10월 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2000년 5월. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, 2003년 11월. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2005년 1월. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, 2006년 7월. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 2007년 8월. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2008년 5월. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, 2008년 1월. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 2008년 8월. [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, 2011년 3월. [USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, 1999년 12월, <http://www.w3.org/TR/1999/REC-html401-19991224>. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, 2008년 11월, <http://www.w3.org/TR/2008/REC-xml-20081126>. Hardt 표준 트랙 [Page 69]
RFC 6749 OAuth 2.0 2012년 10월 12.2. 정보성 참고문헌 [OAuth-HTTP-MAC] Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access Authentication", 진행 중인 작업, 2012년 2월. [OAuth-SAML2] Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", 진행 중인 작업, 2012년 9월. [OAuth-THREATMODEL] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", 진행 중인 작업, 2012년 10월. [OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", 진행 중인 작업, 2010년 1월. [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 2010년 4월. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, 2012년 10월. Hardt 표준 트랙 [Page 70]
RFC 6749 OAuth 2.0 2012년 10월 Appendix A. Augmented Backus-Naur Form (ABNF) 구문 이 절은 [RFC5234]의 표기법을 사용하여 이 명세에서 정의된 요소에 대한 Augmented Backus-Naur Form (ABNF) 구문 설명을 제공한다. 아래 ABNF는 Unicode 코드 포인트 [W3C.REC-xml-20081126]를 기준으로 정의되며, 이러한 문자는 일반적으로 UTF-8로 인코딩된다. 요소는 처음 정의된 순서대로 제시된다. 뒤따르는 일부 정의는 [RFC3986]의 "URI-reference" 정의를 사용한다. 뒤따르는 일부 정의는 다음 공통 정의를 사용한다. VSCHAR = %x20-7E NQCHAR = %x21 / %x23-5B / %x5D-7E NQSCHAR = %x20-21 / %x23-5B / %x5D-7E UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF (UNICODECHARNOCRLF 정의는 [W3C.REC-xml-20081126]의 Section 2.2에 있는 Char 정의를 기반으로 하지만, Carriage Return 및 Linefeed 문자를 생략한다.) A.1. "client_id" 구문 "client_id" 요소는 Section 2.3.1에 정의되어 있다. client-id = *VSCHAR A.2. "client_secret" 구문 "client_secret" 요소는 Section 2.3.1에 정의되어 있다. client-secret = *VSCHAR A.3. "response_type" 구문 "response_type" 요소는 Sections 3.1.1 및 8.4에 정의되어 있다. response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = "_" / DIGIT / ALPHA Hardt 표준 트랙 [Page 71]
RFC 6749 OAuth 2.0 2012년 10월 A.4. "scope" 구문 "scope" 요소는 Section 3.3에 정의되어 있다. scope = scope-token *( SP scope-token ) scope-token = 1*NQCHAR A.5. "state" 구문 "state" 요소는 Sections 4.1.1, 4.1.2, 4.1.2.1, 4.2.1, 4.2.2, 4.2.2.1에 정의되어 있다. state = 1*VSCHAR A.6. "redirect_uri" 구문 "redirect_uri" 요소는 Sections 4.1.1, 4.1.3, 4.2.1에 정의되어 있다. redirect-uri = URI-reference A.7. "error" 구문 "error" 요소는 Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2, 8.5에 정의되어 있다. error = 1*NQSCHAR A.8. "error_description" 구문 "error_description" 요소는 Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2에 정의되어 있다. error-description = 1*NQSCHAR A.9. "error_uri" 구문 "error_uri" 요소는 Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2에 정의되어 있다. error-uri = URI-reference Hardt 표준 트랙 [Page 72]
RFC 6749 OAuth 2.0 2012년 10월 A.10. "grant_type" 구문 "grant_type" 요소는 Sections 4.1.3, 4.3.2, 4.4.2, 4.5, 6에 정의되어 있다. grant-type = grant-name / URI-reference grant-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA A.11. "code" 구문 "code" 요소는 Section 4.1.3에 정의되어 있다. code = 1*VSCHAR A.12. "access_token" 구문 "access_token" 요소는 Sections 4.2.2 및 5.1에 정의되어 있다. access-token = 1*VSCHAR A.13. "token_type" 구문 "token_type" 요소는 Sections 4.2.2, 5.1, 8.1에 정의되어 있다. token-type = type-name / URI-reference type-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" 구문 "expires_in" 요소는 Sections 4.2.2 및 5.1에 정의되어 있다. expires-in = 1*DIGIT A.15. "username" 구문 "username" 요소는 Section 4.3.2에 정의되어 있다. username = *UNICODECHARNOCRLF A.16. "password" 구문 "password" 요소는 Section 4.3.2에 정의되어 있다. password = *UNICODECHARNOCRLF Hardt 표준 트랙 [Page 73]
RFC 6749 OAuth 2.0 2012년 10월 A.17. "refresh_token" 구문 "refresh_token" 요소는 Sections 5.1 및 6에 정의되어 있다. refresh-token = 1*VSCHAR A.18. 엔드포인트 매개변수 구문 새 엔드포인트 매개변수의 구문은 Section 8.2에 정의되어 있다. param-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA Appendix B. application/x-www-form-urlencoded 미디어 유형의 사용 이 명세가 출판된 시점에, "application/x-www-form-urlencoded" 미디어 유형은 [W3C.REC-html401-19991224]의 Section 17.13.4에 정의되어 있었지만 IANA MIME Media Types 레지스트리 (<http://www.iana.org/assignments/media-types>)에는 등록되어 있지 않았다. 또한 그 정의는 non-US-ASCII 문자를 고려하지 않으므로 불완전하다. 이 미디어 유형을 사용하여 payload를 생성할 때 이러한 부족함을 해결하기 위해, 이름과 값은 먼저 UTF-8 문자 인코딩 스킴 [RFC3629]을 사용하여 인코딩되어야 하며(MUST), 그 결과 octet 시퀀스는 이후 [W3C.REC-html401-19991224]에 정의된 escaping 규칙을 사용하여 추가로 인코딩되어야 한다. 이 미디어 유형을 사용하여 payload에서 데이터를 파싱할 때, name/value 인코딩을 역으로 수행한 결과의 이름과 값은 결과적으로 octet 시퀀스로 처리되어야 하며, UTF-8 문자 인코딩 스킴을 사용하여 디코딩되어야 한다. 예를 들어, 여섯 개의 Unicode 코드 포인트 (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), (6) U+20AC (EURO SIGN)로 구성된 값은 아래 octet 시퀀스로 인코딩된다(16진 표기 사용). 20 25 26 2B C2 A3 E2 82 AC 그런 다음 payload에서는 다음과 같이 표현된다. +%25%26%2B%C2%A3%E2%82%AC Hardt 표준 트랙 [Page 74]
RFC 6749 OAuth 2.0 2012년 10월 Appendix C. 감사의 말 최초의 OAuth 2.0 프로토콜 명세는 두 이전 출판물인 OAuth 1.0 커뮤니티 명세 [RFC5849]와 OAuth WRAP (OAuth Web Resource Authorization Profiles) [OAuth-WRAP]를 기반으로 David Recordon이 편집했다. 이후 Eran Hammer는 이 RFC로 발전한 중간 초안들의 많은 부분을 편집했다. Security Considerations 절은 Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin, John Bradley가 초안을 작성했다. "application/x-www-form-urlencoded" 미디어 유형의 사용에 관한 절은 Julian Reschke가 초안을 작성했다. ABNF 절은 Michael B. Jones가 초안을 작성했다. OAuth 1.0 커뮤니티 명세는 Eran Hammer가 편집했으며, Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, Andy Smith가 저술했다. OAuth WRAP 명세는 Dick Hardt가 편집했으며, Brian Eaton, Yaron Y. Goland, Dick Hardt, Allen Tom이 저술했다. 이 명세는 수십 명의 적극적이고 헌신적인 참여자를 포함하는 OAuth Working Group의 작업이다. 특히 다음 개인들은 최종 명세를 형성하고 구성하는 데 기여한 아이디어, 피드백, 문구를 제공했다. Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor, Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones, Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, Skylar Woodward. Hardt 표준 트랙 [Page 75]
RFC 6749 OAuth 2.0 2012년 10월 이 문서는 Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, Derek Atkins의 의장직 아래 작성되었다. 영역 책임자는 Lisa Dusseault, Peter Saint-Andre, Stephen Farrell이었다. 저자 주소 Dick Hardt (편집자) Microsoft EMail: dick.hardt@gmail.com URI: http://dickhardt.org/ Hardt 표준 트랙 [Page 76]