OAuth 2.0 프로토콜의 확장 가능성에 대해 설명합니다.
접근 토큰 유형은 둘 중 한 가지 방법으로 정의될 수 있다: ([Section 11.1]의 절차에 따라)접근 토큰 유형 레지스트리에 등록되거나, 자신의 이름으로 고유한 절대 URI를 사용.
URI 이름을 활용하는 유형들은 공용으로는 적합하지 않거나, 사용되는 리소스 서버의 구현 세부사항에 구체적인, 특정 벤더(vendor)의 구현으로 제한되는 것이 좋다.
모든 다른 유형들은 등록되어야 한다. 유형 이름은 type-name ABNF를 따라야 한다. 유형 정의가 새로운 HTTP 인증 방식을 포함하는 경우, ([RFC2617]에 기술된 대로)유형 이름은 HTTP 인증 방식 이름과 같은 것이 좋다. 토큰 유형 “example”은 예시에서의 사용을 위해 예약되었다.
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
인가 엔드포인트나 토큰 엔드포인트에서 사용하는 새로운 요청이나 응답 파라미터는 [Section 11.2]의 절차에 따라 OAuth 파라미터 레지스트리에 정의되고 등록되어야 한다.
파라미터 이름은 param-name ABNF를 따라야 하며, 파라미터 값 구문은 (e.g., ABNF를 사용하거나 기존 파라미터의 구문을 참조하여)잘 정의되어야 한다.
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
공용으로 사용하기 적합하지 않고 사용되는 인가 서버의 구현 세부사항에 구체적인 등록되지 않은 특정한 벤더의 파라미터 확장은 다른 등록된 값들과 충돌할 일이 없는 (e.g., ‘companyname_‘으로 시작하는)벤더 특징적인 접두사를 활용하는 것이 좋다.
새로운 인가 유형은 “grant_type” 파라미터 사용에 고유한 절대 URI를 할당하여 정의할 수 있다. 해당 확장 승인 유형인 추가적인 토큰 엔드포인트 파라미터를 필요로 하는 경우, [Section 11.2]에 기술된 대로 OAuth 파라미터 레지스트리에 등록돼야 한다.
은인가 엔드포인트에 사용하기 위한 새 응답 유형은 [Section 11.3]의 절차에 따라 인가 엔드포인트 응답 유형 레지스트리에 정의되고 등록돼야 한다. 응답 유형 이름은 response-type ABNF를 따라야 한다.
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
응답 유형이 하나 이상의 스페이스 문자 (%x20)을 포함하면, 순서는 상관 없이 스페이스로 구분된 값들의 리스트로 비교된다. 동일한 값들의 집합의 다른 모든 배치를 포함하는 하나의 순서만 등록할 수 있다.
예를 들어, 응답 유형 “token code”는 이 명세에서 정의되지 않은 채 남겨진다. 하지만, 어떤 확장이 “token code” 응답 유형을 정의하고 등록할 수 있다. 한번 등록되면, 같은 조합은 “code token”으로 등록될 수 없지만, 두 값 모두 같은 응답 유형을 의미하는 데 사용될 수 있다.
프로토콜 확장(i.e., 접근 토큰 유형 확장 파라미터, 또는 확장 승인 유형)이 인가 코드 승인 응답([Section 4.1.2.1])이나, 암시적 승인 오류 응답([Section 4.2.2.1])이나, 토큰 오류 응답([Section 5.2])이나, 리소스 접근 오류 응답([Section 7.2])에 사용되는 추가적인 오류 코드를 필요로 하는 경우 이러한 오류 코드는 정의될 수 있다.
등록된 접근 토큰 유형, 등록된 엔드포인트 파라미터, 혹은 확장 승인 유형과의 결합에 사용되는 경우에는 ([Section 11.4]의 절차에 따라)확장 오류 코드가 등록돼야 한다. 등록되지 않은 확장과 함께 사용되는 오류 코드는 등록될 수 있다.
오류 코드는 error ABNF를 따라야 하며 가능하면 식별되는 이름이 접두어로 사용되는 것이 좋다. 예를 들어, 확장 파라미터 “example”에 설정된 유효하지 않은 값을 식별하는 오류는 “example_invalid”로 명명되는 것이 좋다.
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
네이티브 애플리케이션은 리소스 소유자가 디바이스에 설치하고 실행하는 클라이언트(i.e., 데스크탑 애플리케이션, 네이티브 모바일 애플리케이션)이다. 네이티브 애플리케이션은 보안, 플랫폼의 능력과 종합적인 최종 사용자 경험에 관련된 특별한 고려가 필요하다.
인가 엔드포인트는 클라이언트와 리소스 소유자의 사용자 에이전트 사이에 상호작용을 요구한다. 네이티브 애플리케이션은 외부 사용자 에이전트를 실행하거나 사용자 에이전트를 애플리케이션 안에 내장할 수 있다. 예를 들어:
외부 사용자 에이전트 - 네이티브 애플리케이션이 리다이렉션 URI를 사용하여 인가 서버의 응답을 포착할 수 있다. 클라이언트를 핸들러로 실행하기 위해 운영 체제에 방식을 등록하거나, 자격 증명의 수동 복사-붙여넣기하거나, 로컬 웹 서버 실행이나, 사용자 에이전트 확장 설치, 또는 클라이언트의 통제 아래에 있으면서 서버가 호스트하는 리소스를 식별하는 리다이렉션 URI를 제공함으로써, 네이티브 애플리케이션에서 응답을 사용할 수 있도록 한다.
내장 사용자 에이전트 - 네이티브 애플리케이션은 리소스가 로드되는 동안 발생하는 상태 변화를 모니터링하거나 사용자 에이전트의 쿠키 저장소에 접근하여 내장된 사용자 에이전트와 직접 통신하면서 응답을 얻는다.
외부 혹은 내장 사용자 에이전트 사이에서 선택할 때, 개발자는 다음을 고려해야 한다:
외부 사용자 에이전트는 리소스 소유자가 인가 서버에 이미 활성화된 세션을 가지고 있을 수 있기 때문에, 재 인증할 필요가 없어 완성률(completion-rate)을 높일 수 있다. 이는 최종 사용자 경험에 친숙함과 기능성을 제공한다. 리소스 소유자는 또한 인증에서 사용자 에이전트의 기능이나 확장의 도움(e.g., 패스워드 매니저, 2단계 장치 판독기)에 의존할 수도 있다.
내장 사용자 에이전트는 컨텍스트를 바꾸고 새 창을 열 필요가 없기 때문에 향상된 사용성을 제공할 수도 있다.
내장 사용자 에이전트는 리소스 소유자가 식별되지 않은 창에서 대부분 외부 사용자 에이전트가 가진 시각 보호에 대한 접근 없이 인증하기 때문에 보안 문제를 안고 있다. 내장 사용자 에이전트는 최종 사용자에게 (피싱 공격이 실행하기 쉽게)인증에 대한 식별되지 않은 요청을 믿도록 가르친다.
암시적 승인 유형과 인가 코드 승인 유형 사이에서 선택할 때는, 다음이 고려되어야 한다:
인가 코드 승인 유형을 사용하는 네이티브 애플리케이션은 네이티브 애플리케이션이 클라이언트 자격 증명의 기밀성을 유지하지 못하기 때문에 클라이언트 자격 증명 없이 하는 것이 좋다.
암시적 승인 유형 흐름을 사용할 때, 갱신 토큰은 반환되지 않는다, 즉 접근 토큰이 한번 만료되면 반복해서 인가 프로세스를 요구해야 한다.