OAuth 2.0의 보안상의 고려사항과 명세의 부록입니다.
유연하고 확장 가능한 프레임워크로서, OAuth의 보안 고려사항은 많은 요인들에 달려있다. 다음 섹션들은 [Section 2.1]에 기술된 세 가지 클라이언트 프로파일(웹 애플리케이션, 사용자 에이전트 기반 애플리케이션, 네티이브 애플리케이션)에 초점을 맞춘 가이드라인과 함께 구현자를 제공한다.
프로토콜 설계의 배경 뿐만 아니라 종합적인 OAuth 보안 모델과 분석은 OAuth-THREATMODEL이 제공한다.
인가 서버는 클라이언트 인증을 위한 웹 애플리케이션 클라이언트로 클라이언트 자격 증명을 설정한다. 인가 서버는 클라이언트 패스워드보다 더 강력한 클라이언트 인증 수단을 고려하는 것을 권장한다. 웹 애플리케이션 클라이언트는 클라이언트 패스워드와 다른 클라이언트 자격 증명의 기밀성을 보장해야 한다.
인가 서버는 클라이언트 패스워드나 다른 클라이언트 자격 증명을 클라이언트 인증을 목적으로 네이티브 애플리케이션이나 사용자 에이전트 기반 애플리케이션에 발급해서는 안된다. 인가 서버는 특정 디바이스에 네이티브 애플리케이션 클라이언트의 구체적인 설치를 위해 클라이언트 패스워드 또는 다른 자격 증명을 발급할 수 있다.
클라이언트 인증이 불가능한 경우, 예를 들어, 클라이언트 리다이렉션 URI 등록이나 리소스 소유자에게 신원 확인을 요구하여, 인가 서버는 클라이언트의 신원이 유효한지 확인하는 다른 방법을 채용하는 것이 좋다. 유효한 리다이렉션 URI는 리소스 소유자의 인가를 요청할 때 클라이언트의 신원을 확인하기에는 충분치 않지만 리소스 소유자의 인가를 얻은 후에 자격 증명이 위조 클라이언트에게 전달되는 것을 막는 데 사용될 수는 있다.
인가 서버는 인증되지 않은 클라이언트와 상호작용 시 보안 영향을 고려해야 하며 클라이언트에게 발급된 다른 자격 증명(e.g., 갱신 토큰)의 잠재적 노출을 제한하기 위한 조치를 취해야 한다.
악의적인 클라이언트는 위조한 클라이언트가 자격 증명을 기밀로 유지하지 못하거나 유지할 수 없는 경우, 다른 클라이언트를 위조하여 보호된 리소스에 대한 접근을 얻을 수 있다.
인가 서버는 가능할 때마다 클라이언트를 인증해야 한다. 클라이언트의 특성 때문에 인가 서버가 클라이언트를 인증할 수 없는 경우, 인가 서버는 임의의 리다이렉션 URI 등록을 요구해야 하며 리소스 소유자를 잠재적으로 악의적인 클라이언트로부터 보호하기 위한 다른 방법을 활용하는 것이 좋다. 예를 들어, 인가 서버는 클라이언트와 클라이언트의 발신지(origin)을 식별하는 것을 돕기 위해 리소스 소유자와 관계를 맺을 수 있다.
인가 서버는 명시적인 리소스 소유자 인증을 강제하는 것이 좋으며 리소스 소유자에게 클라이언트와 요청된 인가 영역과 수명에 대한 정보를 제공하는 것이 좋다. 이는 리소스 소유자가 현재 클라이언트의 컨텍스트에서 정보를 검토하고 요청을 인가하거나 거부하는 데에 달려 있다.
인가 서버는 클라이언트 인증이나 반복된 요청이 위조된 것이 아닌 진짜 클라이언트에서 왔음에 대한 보장 없이 반복된 인가 요청을 (활성 리소스 소유자 상호작용 없이)자동으로 처리하지 않는 것이 좋다.
(기밀 접근 토큰 특성 뿐만 아니라)접근 토큰 자격 증명은 전달과 저장에서 기밀이 유지되어야 하며, 인가 서버, 접근 토큰이 유효한 리소스 서버, 접근 토큰이 발급된 클라이언트 사이에서만 공유돼야 한다. 접근 토큰 자격 증명은 [RFC2818]에 정의된 서버 인증과 함께 [Section 1.6]에 기술된 TLS를 사용하여 전송돼야만 한다.
암시적 승인 유형을 사용할 때, 접근 토큰은 인가되지 않은 자들에게 노출할 수 있는 URI 프래그먼트로 전송된다.
인가 서버는 인가되지 않은 자들에 의해 접근 토큰이 생성, 변경 또는 유효한 접근 토큰을 유추할 수 없음을 보장해야 한다.
클라이언트는 필요한 최소한의 범위로 접근 토큰을 요청하는 것이 좋다. 인가 서버는 요청된 범위를 준수하는 방법을 선택할 때 클라이언트 신원을 고려하는 것이 좋으며 요청된 것보다 더 적은 권한의 접근 토큰을 발행할 수도 있다.
이 명세는 리소스 서버가 주어진 클라이언트가 제시한 접근 토큰이 인가 서버가 해당 클라이언트에게 발행했음을 보장하는 방법을 제공하지는 않는다.
인가 서버는 웹 애플리케이션 클라이언트와 네이티브 애플리케이션 클라이언트에게 갱신 토큰을 발급할 수 있다.
갱신 토큰은 전달과 저장에서 기밀이 유지되어야 하며, 인가 서버, 갱신 토큰이 발급된 클라이언트 사이에서만 공유돼야 한다. 인가 서버는 갱신 토큰과 토큰이 발급된 클라이언트 사이의 바인딩을 유지해야 한다. 갱신 토큰은 [RFC2818]에 정의된 서버 인증과 함께 [Section 1.6]에 기술된 TLS를 사용하여 전송돼야만 한다.
인가 서버는 갱신 토큰과, 클라이언트 신원이 인증될 수 있는 경우에는 클라이언트 신원 사이의 바인딩을 확인해야 한다. 클라이언트 인증이 불가능한 경우, 인가 서버는 갱신 토큰 남용을 감지할 수 있는 다른 방법을 배치하는 것이 좋다.
예를 들어, 인가 서버는 매 접근 토큰 갱신 응답마다 새 갱신 토큰이 발급되면 갱신 토큰을 교대할 수도 있다. 이전 갱신 토큰은 유효하지 않지만 인가 서버가 보관한다. 만약 갱신 토큰이 유출됐고 그 뒤에 공격자와 정당한 클라이언트 양쪽에서 사용하면, 그들 중 하나는 유효하지 않은 갱신 토큰을 제시할 것이고, 인가 서버에게 위반 사실을 알릴 것이다.
인가 서버는 인가되지 않은 자들에 의해 갱신 토큰이 생성, 변경 또는 유효한 갱신 토큰을 유추할 수 없음을 보장해야 한다.
인가 코드의 전송은 안전한 채널을 통해 이뤄지는 것이 좋으며, 클라이언트는 URI 식별자가 네트워크 리소스인 경우 자신의 리다이렉션 URI에 TLS 사용을 요구하는 것이 좋다. 인가 코드는 사용자 에이전트 리다이렉션을 통해 전송되기 때문에, 사용자 에이전트의 히스토리와 HTTP referrer 헤더를 통해 공개될 수 있다.
인가 코드는 평문 bearer 자격 증명으로서 동작하며, 인가 서버에서 인가를 승인한 리소스 소유자와 프로세스를 완료하기 위해 클라이언트로 돌아오는 리소스 소유자가 동일함을 확인하는 데 사용된다. 그러므로, 만약 클라이언트가 자신의 리소스 소유자 인증을 위해 인가 코드에 의존하면, 클라이언트 리다이렉션 엔드포인트는 TLS 사용을 요구해야 한다.
인가 코드는 수명이 짧고 한번만 사용돼야 한다. 인가 서버가 인가 코드를 접근 토큰으로 교환하려는 여러 번의 시도를 관측하면, 인가 서버는 유출된 인가 코드에 기반하여 이미 승인된 모든 접근 토큰을 취소하는 것이 좋다.
클라이언트가 인증될 수 있는 경우, 인가 서버는 클라이언트를 인증해야 하고 인가 코드가 같은 클라이언트에게 발급됨을 보장해야 한다.
인가 코드 승인 유형을 사용하여 인가르 요청할 때, 클라이언트는 “redirect_uri” 파라미터를 통해 리다이렉션 URI를 명시할 수 있다. 만약 공격자가 리다이렉션 URI의 값을 조작할 수 있다면, 이는 인가 서버가 리소스 소유자의 사용자 에이전트를 인가 코드와 함께 공격자가 통제하고 있는 URI로 리다이렉트할 수 있게 된다.
공격자는 정당한 클라이언트에서 계정을 생성할 수 있고 인가 흐름을 시작할 수 있다. 공격자의 사용자 에이전트가 승인 접근을 위해 인가 서버로 보내지면, 공격자는 정당한 클라이언트에 의해 인가 URI를 잡고, 클라이언트의 리다이렉션 URI를 공격자의 통제에 있는 URI로 대체한다. 그 뒤에 공격자는 피해자들이 정당한 클라이언트에게 접근을 인가하는 조작된 링크를 따라가도록 한다.
인가 서버에서 한번, 피해자는 정당하고 신뢰되는 클라이언트에서 평범하고 유효한 요청을 받게 된다. 이후에 피해자는 인가 코드와 함께 공격자의 통제에 있는 엔드포인트로 리다이렉트된다. 공격자는 클라이언트가 제공한 원래 리다이렉션 URI를 사용하여 클라이언트에게 인가 코드를 보내서 인가 흐름을 완료한다. 클라이언트는 인가 코드를 접근 토큰과 공격자의 클라이언트 계정으로 향하는 링크로 교환하여 이제 피해자가(클라이언트를 통해) 인가한 보호된 리소스에 대한 접근을 얻을 수 있다.
이러한 공격을 막기 위해, 인가 서버는 인가 코드를 얻는 데 사용된 리다이렉션 URI가 인가 코드를 접근 토큰으로 교환할 때 제공된 리다이렉션 URI와 같음을 보장해야 한다. 인가 서버는 리다이렉션 URI의 등록을 공개 클라이언트에는 요구해야 하며, 기밀 클라이언트에는 요구하는 것이 좋다. 리다이렉션 URI가 요청에서 제공된 경우, 인가 서버는 등록된 값에 대해 유효한지 확인해야 한다.
리소스 소유자 패스워드 자격 증명 승인 유형은 주로 레거시나 마이그레이션을 이유로 사용된다. 클라이언트가 유저네임과 패스워드를 저장하는 위험을 줄이지만 높은 권한을 가진 자격 증명이 클라이언트에 노출될 필요를 없애지는 않는다.
이 프로토콜이 피하고자 하는 패스워드 안티 패턴을 유지하기 때문에, 이 승인 유형은 다른 승인 유형들보다 높은 위험을 지닌다. 클라이언트는 패스워드를 남용할 수 있고, 혹은 (e.g., 로그 파일이나 클라이언트가 유지하는 다른 기록들을 통해)패스워드가 의도치않게 공격자에게 노출될 수 있다.
추가적으로, (자격 증명이 클라이언트에 넘어가는 순간 리소스 소유자의 개입은 끝나므로)리소스 소유자는 인가 프로세스에 대한 통제권이 없기 때문에, 클라이언트는 리소스 소유자가 허락한 것보다 더 넓은 범위로 접근 토큰을 얻을 수도 있다. 인가 서버는 이 승인 유형을 통해 발급한 접근 토큰의 범위와 수명을 고려해야 한다.
인가 서버와 클라이언트는 이 승인 유형을 최소화하는 것이 좋으며 가능한 한 다른 승인 유형을 사용하는 것이 좋다.
접근 토큰, 갱신 토큰, 리소스 소유자 패스워드, 그리고 클라이언트 자격 증명은 알아볼 수 있게 전송돼서는 안된다. 인가 코드는 알아볼 수 있게 전송돼서는 안된다.
안전하지 않은 채널로 전송되거나 안전하지 않게 저장될 수 있으므로, “state”와 “scope” 파라미터는 클라이언트나 리소스 소유자의 민감한 정보를 평문으로 포함하지 않는 것이 좋다.
중간자 공격(man-in-the-middle attack)을 막기 위해, 인가 서버는 인가와 토큰 엔드포인트로 보내지는 임의의 요청에 대해 [RFC2818]에 정의된 대로 서버 인증에 TLS 사용을 요구해야 한다. [RFC6125]와 서버 신원 인증을 위한 요구사항에 따라 클라이언트는 인가 서버의 TLS 인증서가 유효한지 확인해야 한다.
인가 서버는 공격자가 접근 토큰, 인가 코드, 갱신 토큰, 리소스 소유자 패스워드와 클라이언트 자격 증명을 추측하지 못하게 막아야 한다.
공격자가 생성된 토큰을 추측할 가능성은 2^(-128) 이하여야 하며 2^(-160) 이하인 것이 좋다.
인가 서버는 최종 사용자의 자격 증명을 보호할 수 있는 다른 수단들을 활용해야 한다.
이와 유사한 프로토콜들의 광범위한 보급은 최종 사용자들이 패스워드를 묻는 웹사이트로 리다이렉트되는 데에 익숙하게 만들 수 있다. 만약 최종 사용자가 자격 증명을 입력하기 전에 이러한 웹사이트의 진위 여부를 주의깊게 확인하지 않으면 공격자가 이러한 사례를 리소스 소유자의 패스워드를 훔치는 데 악용할 수 있다.
서비스 제공자는 최종 사용자들에게 피싱 공격이 가진 위험성을 알리고 사이트의 진위 여부를 최종 사용자들이 쉽게 확인할 수 있는 메커니즘을 제공해야 한다. 클라이언트 개발자는 (e.g., 외부, 내장)사용자 에이전트와 상호작용하는 방법의 보안 영향과 최종 사용자가 인가 서버의 진위 여부를 확인할 수 있는 능력을 고려해야 한다.
피싱 공격의 위험을 줄이려면, 인가 서버는 최종 사용자 상호작용에 사용되는 매 엔드포인트에 TLS 사용을 요구해야 한다.
사이트 간 요청 위조(CSRF)는 공격자가 피해 최종 사용자의 사용자 에이전트가 (e.g., 잘못된 링크, 이미지, 또는 리다이렉션으로 사용자에게 제공된)악의적인 URI를 따라 신뢰하는 서버로 이동하도록 하는 공격이다.
클라이언트의 리다이렉션 URI에 대한 CSRF 공격은 공격자가 고유한 인가 코드나 접근 토큰을 주입할 수 있게 한다. 이는 클라이언트가 공격자의 보호된 자원이 아닌 공격자의 보호된 자원과 연관된 접근 토큰을 사용하게 할 수 있다(e.g., 피해자의 은행 계정 정보를 공격자가 통제하는 보호된 리소스에 저장).
클라이언트는 자신의 리다이렉션 URI에 대해 CSRF 보호를 구현해야 한다. 주로 리다이렉션 URI 엔드포인트에 전송된 요청이 해당 요청과 사용자 에이전트의 인증 상태(e.g., 사용자 에이전트를 인증하는데 사용된 세션 쿠키의 해시)에 바인드된 값을 포함하도록 요구함으로써 달성된다. 클라이언트는 인가 요청을 보낼 때 이 값을 “state”요청 파라미터를 활용하는 것이 좋다.
최종 사용자로부터 한번 인가를 획득하면, 인가 서버는 최종 사용자의 사용자 에이전트를 클라이언트로 “state” 파라미터에 포함된 바인딩 값과 함께 리다이렉트한다. 바인딩 값은 클라이언트가 바인딩 값과 사용자 에이전트의 인증 상태를 일치시켜 요청의 진위성을 확인할 수 있게 한다. CSRF 보호를 위한 바인딩 값은 ([Section 10.10]에 기술된)추측할 수 없는 값을 담아야 하며, 사용자 에이전트의 인증 상태(e.g., 세션 쿠키, HTML5 로컬 저장소)는 (i.e., same-origin 정책에 의해 보호되는)클라이언트와 사용자 에이전트만이 접근 가능한 위치에 보관돼야 한다.
인가 서버의 인가 엔드포인트에 대한 CSRF 공격은 공격자가 최종 사용자의 개입이나 경고 없이 악의적인 클라이언트에 대한 최종 사용자의 인가를 얻는 결과로 이어질 수도 있다.
인가 서버는 자신의 인가 엔드포인트에 대한 CSRF 보호를 구현해야 하며 악의적인 클라이언트가 리소스 소유자가 의식하는 명시적인 동의 없이 인가를 얻지 못함을 보장해야 한다.
클릭재킹 공격에서, 공격자는 정당한 클라이언트를 틍록한 다음 인증 페이지의 중요한 버튼 아래에 배치되도록 구성된 더미 버튼 세트 위를 덮는 투명한 iframe에서 인가 서버의 인가 엔드포인트 웹 페이지를 로드하는 악의적인 사이트를 만든다. 최종 사용자가 눈에 보이는 잘못된 곳으로 향하는 (“인가” 버튼과 같은)버튼을 클릭할 때, 최종 사용자는 실제로는 인가 페이지 위의 보이지 않는 버튼을 클릭하게 된다. 이는 공격자가 리소스 소유자가 알지 못한 채 공격자의 클라이언트를 승인하도록 한다.
이런 형태의 공격을 막기 위해, 네이티브 애플리케이션은 최종 사용자 인가를 요청할 때 애플리케이션 내에서 내장 브라우저 대신 외부 브라우저를 사용하는 것이 좋다. 대부분의 최신 브라우저들의 경우, (비 표준인) “x-frame-options” 헤더를 사용하는 인가 서버에 의해 iframe 회피가 강제된다. 이 헤더는 두 값을 가질 수 있는데, “deny”와 “sameorigin”으로, 각각 어떤 프레이밍(framing)도 차단하거나 다른 origin인 사이트의 프레이밍만 차단한다. 오래된 브라우저에 대해서는 JavaScript 프레임 버스팅(frame-busting) 기술이 사용될 수 있지만, 모든 브라우저에 효과적이지는 않을 수도 있다.
코드 주입 공격은 애플리케이션이 입력값이나 다른 외부 변수를 검증하지 않고(unsanitized) 사용할 때 발생하며 애플리케이션 로직의 변형을 일으킨다. 이는 공격자가 애플리케이션 디바이스 또는 데이터에 대한 접근을 얻거나, 서비스 거부(denial of service)를 야기하거나 광범위한 악의적인 부수 효과(side-effect)를 만들어낼 수 있다.
인가 서버와 클라이언트는 전달받은 어떤 값도 확인(sanitize)(하고 가능한 경우 유효성도 검사)해야 한다 – 특히, “state”와 “redirect_uri” 파라미터를.
인가 서버, 인가 엔드포인트 및 클라이언트 리다이렉션 엔드포인트는 부적절하게 설정되고 개방 리다이렉터로 운영할 수 있다. 개방 리다이렉터는 파라미터를 사용하여 사용자 에이전트를 자동으로 어떤 유효성 검사도 없이 명시된 위치로 리다이렉트하는 엔드포인트이다.
개방 리다이렉터는 피싱 공격이나 공격자가 친숙하고 믿을 수 있는 목적지의 URI 권한 컴포넌트를 사용해 최종 사용자를 악의적인 사이트에 방문하도록 하는 데에 사용될 수 있다. 추가적으로, 인가 서버는 클라이언트가 리다이렉션 URI의 일부만을 등록하게 할 수도 있는데, 이는 공격자가 클라이언트가 운영하는 개방 리다이렉터를 사용하여 인가 서버의 유효성 검사를 통과하지만 인가 코드와 접근 토큰을 공격자가 통제하는 엔드포인트로 보내는 리다이렉션 URI를 만들 수 있다.
암시적 승인 흐름을 사용하는 공개 클라이언트에 대해, 이 명세는 클라이언트에게 어떤 클라이언트에게 접근 토큰이 발급됐는지를 결정하는 어떤 방법도 제공하지 않는다.
리소스 소유자는 공격자의 악의적인 클라이언트에게 접근 토큰을 승인함으로써 리소스에 대한 접근을 기꺼이 제공할 것이다. 이는 피싱이나 다른 구실에 의한 것일 수도 있다. 공격자는 또한 다른 메커니즘을 통해 토큰을 탈취할 수도 있다. 이후 공격자는 정당한 공개 클라이언트에 접근 토큰을 제공하여 리소스 소유자를 가장할 수 있다.
암시적인 승인 흐름(reponse_type=token)에서, 진짜 접근 토큰을 미리 공격자에게 발급된 것으로 교체하여 공격자는 인가 서버로부터의 응답에서 쉽게 토큰을 교체할 수 있다.
클라이언트의 사용자를 식별하기 위해 백 채널에서 전달된 접근 토큰에 의존하는 네이티브 애플리케이션과 통신하는 서버는 공격자가 임의의 탈취한 토큰을 주입하는 훼손된 애플리케이션을 만들어서 비슷하게 정보가 유출될 수 있다.
오직 리소스 소유자만이 리소스에 대해 유효한 접근 토큰을 제시할 수 있다고 가정하는 어떤 공개 클라이언트도 이 유형의 공격에 취약하다.
이 유형의 공격은 정당한 클라이언트에서 공격자(악의적인 클라이언트)에게 리소스 소유자에 대한 정보를 노출할 수 있다. 이는 또한 공격자가 처음으로 접근 토큰이나 인가 코드를 승인한 리소스 소유자와 동일한 권한으로 정당한 클라이언트에서 연산을 수행할 수 있도록 한다.
클라이언트에 대한 리소스 소유자 인증은 이 명세의 범위를 벗어난다. 어떤 명세도 클라이언트(e.g., 서드 파티 로그인 서비스)가 접근 토큰이 해당 사용을 위해 발급된 것인지 결정할 수 있게 하는 추가적인 보안 메커니즘(e.g., 사용자가 접근 토큰을 제한) 없이 암시적 승인 흐름을 사용해선 안된다.
이 섹션은 이 명세에서 [RFC5234]의 표기를 사용해 정의된 요소들에 대한 Augmented Backus-Naur Form(ABNF) 구문 설명을 제공한다. 아래의 ABNF는 유니코드 코드 포인트[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의 문자 정의에 기반하지만, 캐리지 리턴과 라인피드 문자는 생략한다.)
“client_id” 요소는 [Section 2.3.1]에서 정의되었다:
client-id = *VSCHAR
“client_secret” 요소는 [Section 2.3.1]에서 정의되었다:
client-secret = *VSCHAR
“response_type” 요소는 [Section 3.1.1]과 [8.4]에서 정의되었다:
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
“scope” 요소는 [Section 3.3]에서 정의되었다:
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
“state” 요소는 [Section 4.1.1], [4.1.2], [4.1.2.1], [4.2.1], [4.2.2] 및 [4.2.2.1]에서 정의되었다:
state = 1*VSCHAR
“redirect_uri” 요소는 [Section 4.1.1], [4.1.3] 및 [4.2.1]에서 정의되었다:
redirect-uri = URI-reference
“error” 요소는 [Section 4.1.2.1], [4.2.2.1], [5.2], [7.2] 및 [8.5]에서 정의되었다:
error = 1*NQSCHAR
“error_description” 요소는 [Section 4.1.2.1], [4.2.2.1], [5.2] 및 [7.2]에서 정의되었다:
error-description = 1*NQSCHAR
“error_uri” 요소는 [Section 4.1.2.1], [4.2.2.1], [5.2] 및 [7.2]에서 정의되었다:
error-uri = URI-reference
“grant_type” 요소는 [Section 4.1.3], [4.3.2], [[4.4.2]][section-4-4-2], [[4.5]][section-4-5], [6]에서 정의되었다:
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
“code” 요소는 [Section 4.1.3]에서 정의되었다:
code = 1*VSCHAR
“access_token” 요소는 [Section 4.2.2]와 [5.1]에서 정의되었다:
access-token = 1*VSCHAR
“token_type” 요소는 [Section 4.2.2], [5.1] 및 [8.1]에서 정의되었다:
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
“expires_in” 요소는 [Section 4.2.2]와 [5.1]에서 정의되었다:
expires-in = 1*DIGIT
“username” 요소는 [Section 4.3.2]에서 정의되었다:
username = *UNICODECHARNOCRLF
“password” 요소는 [Section 4.3.2]에서 정의되었다:
password = *UNICODECHARNOCRLF
“refresh_token” 요소는 [Section 5.1]과 [6]에서 정의되었다:
refresh-token = 1*VSCHAR
새로운 엔드포인트 파라미터에 대한 구문은 [Section 8.2]에서 정의되었다:
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
이 명세의 게시되는 시점에서, “application/x-www-form-urlencoded” 미디어 유형은 [W3C.REC-html401-19991224]에 정의됐지만 IANA MIME 미디어 유형 레지스트리((http://www.iana.org/assignments/media-types).)에 등록돼있지 않다. 나아가, non-US-ASCII 문자를 고려하지 않기 때문에 이 정의는 불완전하다.
이 미디어 유형을 사용하는 페이로드를 생성할 때 이 결점을 다루기 위해, 이름과 값은 먼저 UTF-8 문자 인코딩 방식[RFC3629]을 사용하여 인코딩되어야 한다. 그 결과인 옥텟 시퀀스는 [W3C.REC-html401-19991224]에 정의된 이스케이프 규칙을 사용해 추가로 인코딩될 필요가 있다.
이 미디어 유형을 사용하는 페이로드로부터 데이터를 파싱할 때, 이름/값 인코딩을 역순으로 한 값의 결과인 이름과 값은 결과적으로 옥텟 시퀀스로 취급돼야 하며, UTF-8 문자 인코딩 방식을 사용하여 디코딩돼야 한다.
예를 들어, 여섯 개의 유니코드 코드 포인트로 구성된 값 (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)은 (16진수 표기를 사용하여)다음의 옥텟 시퀀스로 인코딩된다:
20 25 26 2B C2 A3 E2 82 AC
그 후 페이로드에서 다음과 같이 표기된다:
+%25%26%2B%C2%A3%E2%82%AC