draft-ietf-oauth-v2-25.txt   draft-ietf-oauth-v2-26.txt 
Network Working Group E. Hammer, Ed. Network Working Group E. Hammer, Ed.
Internet-Draft Internet-Draft
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) D. Recordon
Intended status: Standards Track Facebook Intended status: Standards Track Facebook
Expires: September 9, 2012 D. Hardt Expires: November 2, 2012 D. Hardt
Microsoft Microsoft
March 8, 2012 May 1, 2012
The OAuth 2.0 Authorization Protocol The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-25 draft-ietf-oauth-v2-26
Abstract Abstract
The OAuth 2.0 authorization protocol enables a third-party The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849. in RFC 5849.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2012. This Internet-Draft will expire on November 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 7 1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 8
1.3.1. Authorization Code . . . . . . . . . . . . . . . . . . 8 1.3.1. Authorization Code . . . . . . . . . . . . . . . . . . 8
1.3.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3. Resource Owner Password Credentials . . . . . . . . . 9 1.3.3. Resource Owner Password Credentials . . . . . . . . . 9
1.3.4. Client Credentials . . . . . . . . . . . . . . . . . . 9 1.3.4. Client Credentials . . . . . . . . . . . . . . . . . . 9
1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 10 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 10
1.6. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 12 1.6. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 12
1.7. Interoperability . . . . . . . . . . . . . . . . . . . . 12 1.7. HTTP Redirections . . . . . . . . . . . . . . . . . . . . 12
1.8. Notational Conventions . . . . . . . . . . . . . . . . . 12 1.8. Interoperability . . . . . . . . . . . . . . . . . . . . 12
1.9. Notational Conventions . . . . . . . . . . . . . . . . . 13
2. Client Registration . . . . . . . . . . . . . . . . . . . . . 13 2. Client Registration . . . . . . . . . . . . . . . . . . . . . 13
2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 15 2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 15
2.3. Client Authentication . . . . . . . . . . . . . . . . . . 15 2.3. Client Authentication . . . . . . . . . . . . . . . . . . 15
2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 15 2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 16
2.3.2. Other Authentication Methods . . . . . . . . . . . . . 16 2.3.2. Other Authentication Methods . . . . . . . . . . . . . 17
2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 16 2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 17
3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 17 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 17 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 17
3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 18 3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 18
3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 18 3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 19
3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 20 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Client Authentication . . . . . . . . . . . . . . . . 21 3.2.1. Client Authentication . . . . . . . . . . . . . . . . 21
3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 21 3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 22
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 22 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 23
4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 22 4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 23
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24
4.1.2. Authorization Response . . . . . . . . . . . . . . . . 25 4.1.2. Authorization Response . . . . . . . . . . . . . . . . 25
4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 27 4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 27
4.1.4. Access Token Response . . . . . . . . . . . . . . . . 28 4.1.4. Access Token Response . . . . . . . . . . . . . . . . 28
4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 28 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 29
4.2.1. Authorization Request . . . . . . . . . . . . . . . . 30 4.2.1. Authorization Request . . . . . . . . . . . . . . . . 31
4.2.2. Access Token Response . . . . . . . . . . . . . . . . 31 4.2.2. Access Token Response . . . . . . . . . . . . . . . . 32
4.3. Resource Owner Password Credentials Grant . . . . . . . . 34 4.3. Resource Owner Password Credentials Grant . . . . . . . . 34
4.3.1. Authorization Request and Response . . . . . . . . . . 35 4.3.1. Authorization Request and Response . . . . . . . . . . 36
4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 35 4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 36
4.3.3. Access Token Response . . . . . . . . . . . . . . . . 36 4.3.3. Access Token Response . . . . . . . . . . . . . . . . 37
4.4. Client Credentials Grant . . . . . . . . . . . . . . . . 36 4.4. Client Credentials Grant . . . . . . . . . . . . . . . . 37
4.4.1. Authorization Request and Response . . . . . . . . . . 37 4.4.1. Authorization Request and Response . . . . . . . . . . 38
4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 37 4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 38
4.4.3. Access Token Response . . . . . . . . . . . . . . . . 38 4.4.3. Access Token Response . . . . . . . . . . . . . . . . 39
4.5. Extension Grants . . . . . . . . . . . . . . . . . . . . 38 4.5. Extension Grants . . . . . . . . . . . . . . . . . . . . 39
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 39 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 40
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 39 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 40
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 41 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 41
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 42 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 43
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 43 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 44
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 44 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 44
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 45 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 45
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 45 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 46
8.3. Defining New Authorization Grant Types . . . . . . . . . 46 8.3. Defining New Authorization Grant Types . . . . . . . . . 46
8.4. Defining New Authorization Endpoint Response Types . . . 46 8.4. Defining New Authorization Endpoint Response Types . . . 46
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 46 8.5. Defining Additional Error Codes . . . . . . . . . . . . . 47
9. Native Applications . . . . . . . . . . . . . . . . . . . . . 47 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Client Authentication . . . . . . . . . . . . . . . . . . 48 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 49
10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 49 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 49
10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 49 10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 50
10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 50 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 51
10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 51 10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 51
10.6. Authorization Code Redirection URI Manipulation . . . . . 51 10.6. Authorization Code Redirection URI Manipulation . . . . . 52
10.7. Resource Owner Password Credentials . . . . . . . . . . . 52 10.7. Resource Owner Password Credentials . . . . . . . . . . . 53
10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 52 10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 53
10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 53 10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 53
10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 53 10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 53
10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 53 10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 54
10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 53 10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 54
10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 54 10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 55
10.14. Code Injection and Input Validation . . . . . . . . . . . 55 10.14. Code Injection and Input Validation . . . . . . . . . . . 56
10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 55 10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 56
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 56 11.1. The OAuth Access Token Type Registry . . . . . . . . . . 56
11.1.1. Registration Template . . . . . . . . . . . . . . . . 56 11.1.1. Registration Template . . . . . . . . . . . . . . . . 57
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 57 11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 57
11.2.1. Registration Template . . . . . . . . . . . . . . . . 58 11.2.1. Registration Template . . . . . . . . . . . . . . . . 58
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 58 11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 58
11.3. The OAuth Authorization Endpoint Response Type 11.3. The OAuth Authorization Endpoint Response Type
Registry . . . . . . . . . . . . . . . . . . . . . . . . 60 Registry . . . . . . . . . . . . . . . . . . . . . . . . 60
11.3.1. Registration Template . . . . . . . . . . . . . . . . 61 11.3.1. Registration Template . . . . . . . . . . . . . . . . 61
11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 61 11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 61
11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 61 11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 61
11.4.1. Registration Template . . . . . . . . . . . . . . . . 62 11.4.1. Registration Template . . . . . . . . . . . . . . . . 62
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 63 Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 63
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . 64 13.1. Normative References . . . . . . . . . . . . . . . . . . 64
13.2. Informative References . . . . . . . . . . . . . . . . . 65 13.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
skipping to change at page 5, line 18 skipping to change at page 5, line 18
requests an access restricted resource (protected resource) on the requests an access restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with restricted resources, the resource owner shares its credentials with
the third-party. This creates several problems and limitations: the third-party. This creates several problems and limitations:
o Third-party applications are required to store the resource o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in clear- owner's credentials for future use, typically a password in clear-
text. text.
o Servers are required to support password authentication, despite o Servers are required to support password authentication, despite
the security weaknesses created by passwords. the security weaknesses inherent in passwords.
o Third-party applications gain overly broad access to the resource o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of ability to restrict duration or access to a limited subset of
resources. resources.
o Resource owners cannot revoke access to an individual third-party o Resource owners cannot revoke access to an individual third-party
without revoking access to all third-parties, and must do so by without revoking access to all third-parties, and must do so by
changing their password. changing their password.
o Compromise of any third-party application results in compromise of o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that the end-user's password and all of the data protected by that
password. password.
skipping to change at page 5, line 52 skipping to change at page 5, line 52
access the protected resources hosted by the resource server. access the protected resources hosted by the resource server.
For example, an end-user (resource owner) can grant a printing For example, an end-user (resource owner) can grant a printing
service (client) access to her protected photos stored at a photo service (client) access to her protected photos stored at a photo
sharing service (resource server), without sharing her username and sharing service (resource server), without sharing her username and
password with the printing service. Instead, she authenticates password with the printing service. Instead, she authenticates
directly with a server trusted by the photo sharing service directly with a server trusted by the photo sharing service
(authorization server) which issues the printing service delegation- (authorization server) which issues the printing service delegation-
specific credentials (access token). specific credentials (access token).
This specification is designed for use with HTTP [RFC2616]. The use This specification is designed for use with HTTP ([RFC2616]). The
of OAuth with any transport protocol other than HTTP is undefined. use of OAuth over any other protocol than HTTP is out of scope.
The OAuth 1.0 protocol ([RFC5849]), published as an informational
document, was the result of a small ad-hoc community effort. This
standards-track specification builds on the OAuth 1.0 deployment
experience, as well as additional use cases and extensibility
requirements gathered from the wider IETF community. The OAuth 2.0
protocol is not backward compatible with OAuth 1.0. The two versions
may co-exist on the network and implementations may choose to support
both. However, it is the intention of this specification that new
implementation support OAuth 2.0 as specified in this document, and
that OAuth 1.0 is used only to support existing deployments. The
OAuth 2.0 protocol shares very few implementation details with the
OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should
approach this document without any assumptions as to its structure
and details.
1.1. Roles 1.1. Roles
OAuth defines four roles: OAuth defines four roles:
resource owner resource owner
An entity capable of granting access to a protected resource. An entity capable of granting access to a protected resource.
When the resource owner is a person, it is refered to as an end- When the resource owner is a person, it is referred to as an end-
user. user.
resource server resource server
The server hosting the protected resources, capable of accepting The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens. and responding to protected resource requests using access tokens.
client client
An application making protected resource requests on behalf of the An application making protected resource requests on behalf of the
resource owner and with its authorization. The term client does resource owner and with its authorization. The term client does
not imply any particular implementation characteristics (e.g. not imply any particular implementation characteristics (e.g.
whether the application executes on a server, a desktop, or other whether the application executes on a server, a desktop, or other
devices). devices).
skipping to change at page 7, line 46 skipping to change at page 7, line 49
the types supported by the authorization server. the types supported by the authorization server.
(C) The client requests an access token by authenticating with the (C) The client requests an access token by authenticating with the
authorization server and presenting the authorization grant. authorization server and presenting the authorization grant.
(D) The authorization server authenticates the client and validates (D) The authorization server authenticates the client and validates
the authorization grant, and if valid issues an access token. the authorization grant, and if valid issues an access token.
(E) The client requests the protected resource from the resource (E) The client requests the protected resource from the resource
server and authenticates by presenting the access token. server and authenticates by presenting the access token.
(F) The resource server validates the access token, and if valid, (F) The resource server validates the access token, and if valid,
serves the request. serves the request.
The preferred method for the client to obtain an authorization grant
from the resource owner (depicted in steps (A) and (B)) is to use the
authorization server as an intermediary which is illustrated in
Figure 3.
1.3. Authorization Grant 1.3. Authorization Grant
An authorization grant is a credential representing the resource An authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the owner's authorization (to access its protected resources) used by the
client to obtain an access token. This specification defines four client to obtain an access token. This specification defines four
grant types: authorization code, implicit, resource owner password grant types: authorization code, implicit, resource owner password
credentials, and client credentials, as well as an extensibility credentials, and client credentials, as well as an extensibility
mechanism for defining additional types. mechanism for defining additional types.
1.3.1. Authorization Code 1.3.1. Authorization Code
skipping to change at page 10, line 24 skipping to change at page 10, line 33
1.5. Refresh Token 1.5. Refresh Token
Refresh tokens are credentials used to obtain access tokens. Refresh Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token. token, it is included when issuing an access token (i.e. step (D) in
Figure 1).
A refresh token is a string representing the authorization granted to A refresh token is a string representing the authorization granted to
the client by the resource owner. The string is usually opaque to the client by the resource owner. The string is usually opaque to
the client. The token denotes an identifier used to retrieve the the client. The token denotes an identifier used to retrieve the
authorization information. Unlike access tokens, refresh tokens are authorization information. Unlike access tokens, refresh tokens are
intended for use only with authorization servers and are never sent intended for use only with authorization servers and are never sent
to resource servers. to resource servers.
+--------+ +---------------+ +--------+ +---------------+
| |--(A)------- Authorization Grant --------->| | | |--(A)------- Authorization Grant --------->| |
skipping to change at page 12, line 14 skipping to change at page 12, line 14
(H) The authorization server authenticates the client and validates (H) The authorization server authenticates the client and validates
the refresh token, and if valid issues a new access token (and the refresh token, and if valid issues a new access token (and
optionally, a new refresh token). optionally, a new refresh token).
Steps C, D, E, and F are outside the scope of this specification as Steps C, D, E, and F are outside the scope of this specification as
described in Section 7. described in Section 7.
1.6. TLS Version 1.6. TLS Version
Whenever TLS is required by this specification, the appropriate Whenever TLS is used by this specification, the appropriate version
version (or versions) of TLS will vary over time, based on the (or versions) of TLS will vary over time, based on the widespread
widespread deployment and known security vulnerabilities. At the deployment and known security vulnerabilities. At the time of this
time of this writing, TLS version 1.2 [RFC5246] is the most recent writing, TLS version 1.2 [RFC5246] is the most recent version, but
version, but has a very limited deployment base and might not be has a very limited deployment base and might not be readily available
readily available for implementation. TLS version 1.0 [RFC2246] is for implementation. TLS version 1.0 [RFC2246] is the most widely
the most widely deployed version, and will provide the broadest deployed version, and will provide the broadest interoperability.
interoperability.
Implementations MAY also support additional transport-layer Implementations MAY also support additional transport-layer security
mechanisms that meet their security requirements. mechanisms that meet their security requirements.
1.7. Interoperability 1.7. HTTP Redirections
This specification makes extensive use of HTTP redirections, in which
the client or the authorization server direct the resource owner's
user-agent to another destination. While the examples in this
specification show the use of the HTTP 302 status code, any other
method available via the user-agent to accomplish this redirection is
allowed and is considered to be an implementation detail.
1.8. Interoperability
OAuth 2.0 provides a rich authorization framework with well-defined OAuth 2.0 provides a rich authorization framework with well-defined
security properties. However, as a rich and highly extensible security properties. However, as a rich and highly extensible
framework with many optional components, on its own, this framework with many optional components, on its own, this
specification is likely to produce a wide range of non-interoperable specification is likely to produce a wide range of non-interoperable
implementations. In addition, this specification leaves a few implementations.
required components partially or fully undefined (e.g. client
registration, authorization server capabilities, endpoint discovery).
This protocol was designed with the clear expectation that future In addition, this specification leaves a few required components
partially or fully undefined (e.g. client registration, authorization
server capabilities, endpoint discovery). Without these components,
clients must be manually and specifically configured against a
specific authorization server and resource server in order to
interoperate.
This framework was designed with the clear expectation that future
work will define prescriptive profiles and extensions necessary to work will define prescriptive profiles and extensions necessary to
achieve full web-scale interoperability. achieve full web-scale interoperability.
1.8. Notational Conventions 1.9. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in [RFC2119]. specification are to be interpreted as described in [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
Certain security-related terms are to be understood in the sense Certain security-related terms are to be understood in the sense
defined in [RFC4949]. These terms include, but are not limited to, defined in [RFC4949]. These terms include, but are not limited to,
'attack', 'authentication', 'authorization', 'certificate', "attack", "authentication", "authorization", "certificate",
'confidentiality', 'credential', 'encryption', 'identity', 'sign', "confidentiality", "credential", "encryption", "identity", "sign",
'signature', 'trust', 'validate', and 'verify'. "signature", "trust", "validate", and "verify".
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
2. Client Registration 2. Client Registration
Before initiating the protocol, the client registers with the Before initiating the protocol, the client registers with the
authorization server. The means through which the client registers authorization server. The means through which the client registers
with the authorization server are beyond the scope of this with the authorization server are beyond the scope of this
specification, but typically involve end-user interaction with an specification, but typically involve end-user interaction with an
skipping to change at page 13, line 26 skipping to change at page 13, line 40
Client registration does not require a direct interaction between the Client registration does not require a direct interaction between the
client and the authorization server. When supported by the client and the authorization server. When supported by the
authorization server, registration can rely on other means for authorization server, registration can rely on other means for
establishing trust and obtaining the required client properties (e.g. establishing trust and obtaining the required client properties (e.g.
redirection URI, client type). For example, registration can be redirection URI, client type). For example, registration can be
accomplished using a self-issued or third-party-issued assertion, or accomplished using a self-issued or third-party-issued assertion, or
by the authorization server performing client discovery using a by the authorization server performing client discovery using a
trusted channel. trusted channel.
When registering a client, the client developer: When registering a client, the client developer SHALL:
o specifies the client type as described in Section 2.1, o specifies the client type as described in Section 2.1,
o provides its client redirection URIs as described in o provides its client redirection URIs as described in
Section 3.1.2, and Section 3.1.2, and
o includes any other information required by the authorization o includes any other information required by the authorization
server (e.g. application name, website, description, logo image, server (e.g. application name, website, description, logo image,
the acceptance of legal terms). the acceptance of legal terms).
2.1. Client Types 2.1. Client Types
skipping to change at page 14, line 8 skipping to change at page 14, line 25
client authentication using other means. client authentication using other means.
public public
Clients incapable of maintaining the confidentiality of their Clients incapable of maintaining the confidentiality of their
credentials (e.g. clients executing on the device used by the credentials (e.g. clients executing on the device used by the
resource owner such as an installed native application or a web resource owner such as an installed native application or a web
browser-based application), and incapable of secure client browser-based application), and incapable of secure client
authentication via any other means. authentication via any other means.
The client type designation is based on the authorization server's The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure definition of secure authentication and its acceptable exposure
levels of client credentials. levels of client credentials. The authorization server SHOULD NOT
make assumptions about the client type.
The authorization server SHOULD NOT make assumptions about the client
type, nor accept the type information provided by the client
developer without first establishing trust.
A client application consisting of multiple components, each with its A client may be implemented as a distributed set of components, each
own client type (e.g. a distributed client with both a confidential with a different client type and security context (e.g. a distributed
server-based component and a public browser-based component), MUST client with both a confidential server-based component and a public
register each component separately as a different client to ensure browser-based component). If the authorization server does not
proper handling by the authorization server. The authorization provide support for such clients, or does not provide guidance with
server MAY provider tools to manage such complex clients through a regard to their registration, the client SHOULD register each
single administration interface. component as a separate client.
This specification has been designed around the following client This specification has been designed around the following client
profiles: profiles:
web application web application
A web application is a confidential client running on a web A web application is a confidential client running on a web
server. Resource owners access the client via an HTML user server. Resource owners access the client via an HTML user
interface rendered in a user-agent on the device used by the interface rendered in a user-agent on the device used by the
resource owner. The client credentials as well as any access resource owner. The client credentials as well as any access
token issued to the client are stored on the web server and are token issued to the client are stored on the web server and are
skipping to change at page 15, line 11 skipping to change at page 15, line 24
application may interact with. On some platforms these application may interact with. On some platforms these
credentials might be protected from other applications residing on credentials might be protected from other applications residing on
the same device. the same device.
2.2. Client Identifier 2.2. Client Identifier
The authorization server issues the registered client a client The authorization server issues the registered client a client
identifier - a unique string representing the registration identifier - a unique string representing the registration
information provided by the client. The client identifier is not a information provided by the client. The client identifier is not a
secret, it is exposed to the resource owner, and MUST NOT be used secret, it is exposed to the resource owner, and MUST NOT be used
alone for client authentication. alone for client authentication. The client identifier is unique to
the authorization server.
The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size
of any identifier it issues.
2.3. Client Authentication 2.3. Client Authentication
If the client type is confidential, the client and authorization If the client type is confidential, the client and authorization
server establish a client authentication method suitable for the server establish a client authentication method suitable for the
security requirements of the authorization server. The authorization security requirements of the authorization server. The authorization
server MAY accept any form of client authentication meeting its server MAY accept any form of client authentication meeting its
security requirements. security requirements.
Confidential clients are typically issued (or establish) a set of Confidential clients are typically issued (or establish) a set of
skipping to change at page 16, line 13 skipping to change at page 16, line 31
parameters: parameters:
client_id client_id
REQUIRED. The client identifier issued to the client during REQUIRED. The client identifier issued to the client during
the registration process described by Section 2.2. the registration process described by Section 2.2.
client_secret client_secret
REQUIRED. The client secret. The client MAY omit the REQUIRED. The client secret. The client MAY omit the
parameter if the client secret is an empty string. parameter if the client secret is an empty string.
Including the client credentials in the request body using the two Including the client credentials in the request body using the two
parameters is NOT RECOMMENDED, and should be limited to clients parameters is NOT RECOMMENDED, and SHOULD be limited to clients
unable to directly utilize the HTTP Basic authentication scheme (or unable to directly utilize the HTTP Basic authentication scheme (or
other password-based HTTP authentication schemes). The parameters other password-based HTTP authentication schemes). The parameters
can only be transmitted in the request body and MUST NOT be included can only be transmitted in the request body and MUST NOT be included
in the request URI. in the request URI.
For example, requesting to refresh an access token (Section 6) using For example, requesting to refresh an access token (Section 6) using
the body parameters (extra line breaks are for display purposes the body parameters (extra line breaks are for display purposes
only): only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
The authorization server MUST require TLS as described in Section 1.6 The authorization server MUST require the use of TLS as described in
when sending requests using password authentication. Section 1.6 when sending requests using password authentication.
Since this client authentication method involves a password, the Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against authorization server MUST protect any endpoint utilizing it against
brute force attacks. brute force attacks.
2.3.2. Other Authentication Methods 2.3.2. Other Authentication Methods
The authorization server MAY support any suitable HTTP authentication The authorization server MAY support any suitable HTTP authentication
scheme matching its security requirements. When using other scheme matching its security requirements. When using other
authentication methods, the authorization server MUST define a authentication methods, the authorization server MUST define a
skipping to change at page 17, line 44 skipping to change at page 18, line 17
authorization endpoint are beyond the scope of this specification, authorization endpoint are beyond the scope of this specification,
but the location is typically provided in the service documentation. but the location is typically provided in the service documentation.
The endpoint URI MAY include an "application/x-www-form-urlencoded" The endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted ([W3C.REC-html401-19991224]) query component ([RFC3986] formatted ([W3C.REC-html401-19991224]) query component ([RFC3986]
section 3.4), which MUST be retained when adding additional query section 3.4), which MUST be retained when adding additional query
parameters. The endpoint URI MUST NOT include a fragment component. parameters. The endpoint URI MUST NOT include a fragment component.
Since requests to the authorization endpoint result in user Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in the authentication and the transmission of clear-text credentials (in the
HTTP response), the authorization server MUST require TLS as HTTP response), the authorization server MUST require the use of TLS
described in Section 1.6 when sending requests to the authorization as described in Section 1.6 when sending requests to the
endpoint. authorization endpoint.
The authorization server MUST support the use of the HTTP "GET" The authorization server MUST support the use of the HTTP "GET"
method [RFC2616] for the authorization endpoint, and MAY support the method [RFC2616] for the authorization endpoint, and MAY support the
use of the "POST" method as well. use of the "POST" method as well.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore omitted from the request. The authorization server MUST ignore
unrecognized request parameters. Request and response parameters unrecognized request parameters. Request and response parameters
MUST NOT be included more than once. MUST NOT be included more than once.
skipping to change at page 19, line 9 skipping to change at page 19, line 31
3.1.2.1. Endpoint Request Confidentiality 3.1.2.1. Endpoint Request Confidentiality
The redirection endpoint SHOULD require the use of TLS as described The redirection endpoint SHOULD require the use of TLS as described
in Section 1.6 when the requested response type is "code" or "token", in Section 1.6 when the requested response type is "code" or "token",
or when the redirection request will result in the transmission of or when the redirection request will result in the transmission of
sensitive credentials over an open network. This specification does sensitive credentials over an open network. This specification does
not mandate the use of TLS because at the time of this writing, not mandate the use of TLS because at the time of this writing,
requiring clients to deploy TLS is a significant hurdle for many requiring clients to deploy TLS is a significant hurdle for many
client developers. If TLS is not available, the authorization server client developers. If TLS is not available, the authorization server
SHOULD warn the resource owner about the insecure endpoint prior to SHOULD warn the resource owner about the insecure endpoint prior to
redirection. redirection (e.g. display a message during the authorization
request).
Lack of transport-layer security can have a severe impact on the Lack of transport-layer security can have a severe impact on the
security of the client and the protected resources it is authorized security of the client and the protected resources it is authorized
to access. The use of transport-layer security is particularly to access. The use of transport-layer security is particularly
critical when the authorization process is used as a form of critical when the authorization process is used as a form of
delegated end-user authentication by the client (e.g. third-party delegated end-user authentication by the client (e.g. third-party
sign-in service). sign-in service).
3.1.2.2. Registration Requirements 3.1.2.2. Registration Requirements
The authorization server MUST require the following clients to The authorization server MUST require the following clients to
register their redirection endpoint: register their redirection endpoint:
o Public clients. o Public clients.
o Confidential clients utilizing the implicit grant type. o Confidential clients utilizing the implicit grant type.
The authorization server SHOULD require all clients to register their The authorization server SHOULD require all clients to register their
redirection endpoint prior to utilizing the authorization endpoint redirection endpoint prior to utilizing the authorization endpoint.
The authorization server SHOULD require the client to provide the The authorization server SHOULD require the client to provide the
complete redirection URI (the client MAY use the "state" request complete redirection URI (the client MAY use the "state" request
parameter to achieve per-request customization). If requiring the parameter to achieve per-request customization). If requiring the
registration of the complete redirection URI is not possible, the registration of the complete redirection URI is not possible, the
authorization server SHOULD require the registration of the URI authorization server SHOULD require the registration of the URI
scheme, authority, and path (allowing the client to dynamically vary scheme, authority, and path (allowing the client to dynamically vary
only the query component of the redirection URI when requesting only the query component of the redirection URI when requesting
authorization). authorization).
skipping to change at page 21, line 7 skipping to change at page 21, line 28
endpoint are beyond the scope of this specification but is typically endpoint are beyond the scope of this specification but is typically
provided in the service documentation. provided in the service documentation.
The endpoint URI MAY include an "application/x-www-form-urlencoded" The endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted ([W3C.REC-html401-19991224]) query component ([RFC3986] formatted ([W3C.REC-html401-19991224]) query component ([RFC3986]
section 3.4), which MUST be retained when adding additional query section 3.4), which MUST be retained when adding additional query
parameters. The endpoint URI MUST NOT include a fragment component. parameters. The endpoint URI MUST NOT include a fragment component.
Since requests to the token endpoint result in the transmission of Since requests to the token endpoint result in the transmission of
clear-text credentials (in the HTTP request and response), the clear-text credentials (in the HTTP request and response), the
authorization server MUST require TLS as described in Section 1.6 authorization server MUST require the use of TLS as described in
when sending requests to the token endpoint. Section 1.6 when sending requests to the token endpoint.
The client MUST use the HTTP "POST" method when making access token The client MUST use the HTTP "POST" method when making access token
requests. requests.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore omitted from the request. The authorization server MUST ignore
unrecognized request parameters. Request and response parameters unrecognized request parameters. Request and response parameters
MUST NOT be included more than once. MUST NOT be included more than once.
3.2.1. Client Authentication 3.2.1. Client Authentication
skipping to change at page 25, line 49 skipping to change at page 26, line 21
For example, the authorization server redirects the user-agent by For example, the authorization server redirects the user-agent by
sending the following HTTP response: sending the following HTTP response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz &state=xyz
The client MUST ignore unrecognized response parameters. The The client MUST ignore unrecognized response parameters. The
authorization code string size is left undefined by this authorization code string size is left undefined by this
specification. The client should avoid making assumptions about code specification. The client should avoid making assumptions about code
value sizes. The authorization server should document the size of value sizes. The authorization server SHOULD document the size of
any value it issues. any value it issues.
4.1.2.1. Error Response 4.1.2.1. Error Response
If the request fails due to a missing, invalid, or mismatching If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid, redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the the authorization server SHOULD inform the resource owner of the
error, and MUST NOT automatically redirect the user-agent to the error, and MUST NOT automatically redirect the user-agent to the
invalid redirection URI. invalid redirection URI.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
invalid parameter value, or is otherwise malformed. invalid parameter value, includes a parameter more than
once, or is otherwise malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an authorization The client is not authorized to request an authorization
code using this method. code using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
request. request.
unsupported_response_type unsupported_response_type
The authorization server does not support obtaining an The authorization server does not support obtaining an
authorization code using this method. authorization code using this method.
invalid_scope invalid_scope
The requested scope is invalid, unknown, or malformed. The requested scope is invalid, unknown, or malformed.
server_error server_error
The authorization server encountered an unexpected The authorization server encountered an unexpected
skipping to change at page 32, line 43 skipping to change at page 33, line 30
Developers should note that some user-agents do not support the Developers should note that some user-agents do not support the
inclusion of a fragment component in the HTTP "Location" response inclusion of a fragment component in the HTTP "Location" response
header field. Such clients will require using other methods for header field. Such clients will require using other methods for
redirecting the client than a 3xx redirection response. For example, redirecting the client than a 3xx redirection response. For example,
returning an HTML page which includes a 'continue' button with an returning an HTML page which includes a 'continue' button with an
action linked to the redirection URI. action linked to the redirection URI.
The client MUST ignore unrecognized response parameters. The access The client MUST ignore unrecognized response parameters. The access
token string size is left undefined by this specification. The token string size is left undefined by this specification. The
client should avoid making assumptions about value sizes. The client should avoid making assumptions about value sizes. The
authorization server should document the size of any value it issues. authorization server SHOULD document the size of any value it issues.
4.2.2.1. Error Response 4.2.2.1. Error Response
If the request fails due to a missing, invalid, or mismatching If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid, redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the the authorization server SHOULD inform the resource owner of the
error, and MUST NOT automatically redirect the user-agent to the error, and MUST NOT automatically redirect the user-agent to the
invalid redirection URI. invalid redirection URI.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
skipping to change at page 33, line 14 skipping to change at page 34, line 4
invalid redirection URI. invalid redirection URI.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the fragment component of the redirection URI using the parameters to the fragment component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
invalid parameter value, or is otherwise malformed. invalid parameter value, includes a parameter more than
once, or is otherwise malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an access token The client is not authorized to request an access token
using this method. using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
request. request.
unsupported_response_type unsupported_response_type
The authorization server does not support obtaining an The authorization server does not support obtaining an
access token using this method. access token using this method.
invalid_scope invalid_scope
skipping to change at page 36, line 11 skipping to change at page 37, line 4
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=password&username=johndoe&password=A3ddj3w grant_type=password&username=johndoe&password=A3ddj3w
The authorization server MUST: The authorization server MUST:
o require client authentication for confidential clients or for any o require client authentication for confidential clients or for any
client that was issued client credentials (or with other client that was issued client credentials (or with other
authentication requirements), authentication requirements),
o authenticate the client if client authentication is included, and o authenticate the client if client authentication is included, and
o validate the resource owner password credentials. o validate the resource owner password credentials using its
existing password validation algorithm.
Since this access token request utilizes the resource owner's Since this access token request utilizes the resource owner's
password, the authorization server MUST protect the endpoint against password, the authorization server MUST protect the endpoint against
brute force attacks (e.g. using rate-limitation or generating brute force attacks (e.g. using rate-limitation or generating
alerts). alerts).
4.3.3. Access Token Response 4.3.3. Access Token Response
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh authorization server issues an access token and optional refresh
skipping to change at page 40, line 46 skipping to change at page 41, line 32
"access_token":"2YotnFZFEjr1zCsicMWpAA", "access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example", "token_type":"example",
"expires_in":3600, "expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value" "example_parameter":"example_value"
} }
The client MUST ignore unrecognized value names in the response. The The client MUST ignore unrecognized value names in the response. The
sizes of tokens and other values received from the authorization sizes of tokens and other values received from the authorization
server are left undefined. The client should avoid making server are left undefined. The client should avoid making
assumptions about value sizes. The authorization server should assumptions about value sizes. The authorization server SHOULD
document the size of any value it issues. document the size of any value it issues.
5.2. Error Response 5.2. Error Response
The authorization server responds with an HTTP 400 (Bad Request) The authorization server responds with an HTTP 400 (Bad Request)
status code and includes the following parameters with the response: status code (unless specified otherwise) and includes the following
parameters with the response:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
unsupported parameter value (other than grant type), unsupported parameter value (other than grant type),
repeats a parameter, includes multiple credentials, repeats a parameter, includes multiple credentials,
utilizes more than one mechanism for authenticating the utilizes more than one mechanism for authenticating the
client, or is otherwise malformed. client, or is otherwise malformed.
invalid_client invalid_client
Client authentication failed (e.g. unknown client, no Client authentication failed (e.g. unknown client, no
client authentication included, or unsupported client authentication included, or unsupported
authentication method). The authorization server MAY authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization" client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code, and respond with an HTTP 401 (Unauthorized) status code, and
include the "WWW-Authenticate" response header field include the "WWW-Authenticate" response header field
skipping to change at page 47, line 6 skipping to change at page 47, line 38
Extension error codes MUST be registered (following the procedures in Extension error codes MUST be registered (following the procedures in
Section 11.4) if the extension they are used in conjunction with is a Section 11.4) if the extension they are used in conjunction with is a
registered access token type, a registered endpoint parameter, or an registered access token type, a registered endpoint parameter, or an
extension grant type. Error codes used with unregistered extensions extension grant type. Error codes used with unregistered extensions
MAY be registered. MAY be registered.
Error codes MUST conform to the error-code ABNF, and SHOULD be Error codes MUST conform to the error-code ABNF, and SHOULD be
prefixed by an identifying name when possible. For example, an error prefixed by an identifying name when possible. For example, an error
identifying an invalid value set to the extension parameter "example" identifying an invalid value set to the extension parameter "example"
should be named "example_invalid". SHOULD be named "example_invalid".
error-code = ALPHA *error-char error-code = ALPHA *error-char
error-char = "-" / "." / "_" / DIGIT / ALPHA error-char = "-" / "." / "_" / DIGIT / ALPHA
9. Native Applications 9. Native Applications
Native applications are clients installed and executed on the device Native applications are clients installed and executed on the device
used by the resource owner (i.e. desktop application, native mobile used by the resource owner (i.e. desktop application, native mobile
application). Native applications require special consideration application). Native applications require special consideration
related to security, platform capabilities, and overall end-user related to security, platform capabilities, and overall end-user
skipping to change at page 50, line 19 skipping to change at page 50, line 48
The authorization server MUST ensure that access tokens cannot be The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens by generated, modified, or guessed to produce valid access tokens by
unauthorized parties. unauthorized parties.
The client SHOULD request access tokens with the minimal scope The client SHOULD request access tokens with the minimal scope
necessary. The authorization server SHOULD take the client identity necessary. The authorization server SHOULD take the client identity
into account when choosing how to honor the requested scope, and MAY into account when choosing how to honor the requested scope, and MAY
issue an access token with a less rights than requested. issue an access token with a less rights than requested.
This specification does not provide any methods for the resource
server to ensure that an access token presented to it by a given
client, was issued to the that client by the authorization server.
10.4. Refresh Tokens 10.4. Refresh Tokens
Authorization servers MAY issue refresh tokens to web application Authorization servers MAY issue refresh tokens to web application
clients and native application clients. clients and native application clients.
Refresh tokens MUST be kept confidential in transit and storage, and Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was the binding between a refresh token and the client to whom it was
issued. Refresh tokens MUST only be transmitted using TLS as issued. Refresh tokens MUST only be transmitted using TLS as
skipping to change at page 51, line 8 skipping to change at page 51, line 39
legitimate client, one of them will present an invalidated refresh legitimate client, one of them will present an invalidated refresh
token which will inform the authorization server of the breach. token which will inform the authorization server of the breach.
The authorization server MUST ensure that refresh tokens cannot be The authorization server MUST ensure that refresh tokens cannot be
generated, modified, or guessed to produce valid refresh tokens by generated, modified, or guessed to produce valid refresh tokens by
unauthorized parties. unauthorized parties.
10.5. Authorization Codes 10.5. Authorization Codes
The transmission of authorization codes SHOULD be made over a secure The transmission of authorization codes SHOULD be made over a secure
channel, and the client SHOULD implement TLS for use with its channel, and the client SHOULD require the use of TLS with its
redirection URI if the URI identifies a network resource. Since redirection URI if the URI identifies a network resource. Since
authorization codes are transmitted via user-agent redirections, they authorization codes are transmitted via user-agent redirections, they
could potentially be disclosed through user-agent history and HTTP could potentially be disclosed through user-agent history and HTTP
referrer headers. referrer headers.
Authorization codes operate as plaintext bearer credentials, used to Authorization codes operate as plaintext bearer credentials, used to
verify that the resource owner who granted authorization at the verify that the resource owner who granted authorization at the
authorization server is the same resource owner returning to the authorization server is the same resource owner returning to the
client to complete the process. Therefore, if the client relies on client to complete the process. Therefore, if the client relies on
the authorization code for its own resource owner authentication, the the authorization code for its own resource owner authentication, the
client redirection endpoint MUST require TLS. client redirection endpoint MUST require the use of TLS.
Authorization codes MUST be short lived and single use. If the Authorization codes MUST be short lived and single use. If the
authorization server observes multiple attempts to exchange an authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server authorization code for an access token, the authorization server
SHOULD attempt to revoke all access tokens already granted based on SHOULD attempt to revoke all access tokens already granted based on
the compromised authorization code. the compromised authorization code.
If the client can be authenticated, the authorization servers MUST If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was authenticate the client and ensure that the authorization code was
issued to the same client. issued to the same client.
skipping to change at page 53, line 8 skipping to change at page 53, line 41
credentials MUST NOT be transmitted in the clear. Authorization credentials MUST NOT be transmitted in the clear. Authorization
codes SHOULD NOT be transmitted in the clear. codes SHOULD NOT be transmitted in the clear.
The "state" and "scope" parameters SHOULD NOT include sensitive The "state" and "scope" parameters SHOULD NOT include sensitive
client or resource owner information in plain text as they can be client or resource owner information in plain text as they can be
transmitted over insecure channels or stored insecurely. transmitted over insecure channels or stored insecurely.
10.9. Endpoints Authenticity 10.9. Endpoints Authenticity
In order to prevent man-in-the-middle attacks, the authorization In order to prevent man-in-the-middle attacks, the authorization
server MUST implement and require TLS with server authentication as server MUST require the use of TLS with server authentication as
defined by [RFC2818] for any request sent to the authorization and defined by [RFC2818] for any request sent to the authorization and
token endpoints. The client MUST validate the authorization server's token endpoints. The client MUST validate the authorization server's
TLS certificate as defined by [RFC6125], and in accordance with its TLS certificate as defined by [RFC6125], and in accordance with its
requirements for server identity authentication. requirements for server identity authentication.
10.10. Credentials Guessing Attacks 10.10. Credentials Guessing Attacks
The authorization server MUST prevent attackers from guessing access The authorization server MUST prevent attackers from guessing access
tokens, authorization codes, refresh tokens, resource owner tokens, authorization codes, refresh tokens, resource owner
passwords, and client credentials. passwords, and client credentials.
skipping to change at page 53, line 45 skipping to change at page 54, line 30
Service providers should attempt to educate end-users about the risks Service providers should attempt to educate end-users about the risks
phishing attacks pose, and should provide mechanisms that make it phishing attacks pose, and should provide mechanisms that make it
easy for end-users to confirm the authenticity of their sites. easy for end-users to confirm the authenticity of their sites.
Client developers should consider the security implications of how Client developers should consider the security implications of how
they interact with the user-agent (e.g., external, embedded), and the they interact with the user-agent (e.g., external, embedded), and the
ability of the end-user to verify the authenticity of the ability of the end-user to verify the authenticity of the
authorization server. authorization server.
To reduce the risk of phishing attacks, the authorization servers To reduce the risk of phishing attacks, the authorization servers
MUST utilize TLS on every endpoint used for end-user interaction. MUST require the use of TLS on every endpoint used for end-user
interaction.
10.12. Cross-Site Request Forgery 10.12. Cross-Site Request Forgery
Cross-site request forgery (CSRF) is an exploit in which an attacker Cross-site request forgery (CSRF) is an exploit in which an attacker
causes the user-agent of a victim end-user to follow a malicious URI causes the user-agent of a victim end-user to follow a malicious URI
(e.g. provided to the user-agent as a misleading link, image, or (e.g. provided to the user-agent as a misleading link, image, or
redirection) to a trusting server (usually established via the redirection) to a trusting server (usually established via the
presence of a valid session cookie). presence of a valid session cookie).
A CSRF attack against the client's redirection URI allows an attacker A CSRF attack against the client's redirection URI allows an attacker
skipping to change at page 56, line 4 skipping to change at page 56, line 36
to get end-users to visit malicious sites by making the URI's to get end-users to visit malicious sites by making the URI's
authority look like a familiar and trusted destination. In addition, authority look like a familiar and trusted destination. In addition,
if the authorization server allows the client to register only part if the authorization server allows the client to register only part
of the redirection URI, an attacker can use an open redirector of the redirection URI, an attacker can use an open redirector
operated by the client to construct a redirection URI that will pass operated by the client to construct a redirection URI that will pass
the authorization server validation but will send the authorization the authorization server validation but will send the authorization
code or access token to an endpoint under the control of the code or access token to an endpoint under the control of the
attacker. attacker.
11. IANA Considerations 11. IANA Considerations
11.1. The OAuth Access Token Type Registry 11.1. The OAuth Access Token Type Registry
This specification establishes the OAuth access token type registry. This specification establishes the OAuth access token type registry.
Access token types are registered on the advice of one or more Access token types are registered with a Specification Required
Designated Experts (appointed by the IESG or their delegate), with a ([RFC5226]) after a two weeks review period on the [TBD]@ietf.org
Specification Required (using terminology from [RFC5226]). However, mailing list, on the advice of one or more Designated Experts.
to allow for the allocation of values prior to publication, the However, to allow for the allocation of values prior to publication,
Designated Expert(s) may approve registration once they are satisfied the Designated Expert(s) may approve registration once they are
that such a specification will be published. satisfied that such a specification will be published.
Registration requests should be sent to the [TBD]@ietf.org mailing
list for review and comment, with an appropriate subject (e.g.,
"Request for access token type: example"). [[ Note to RFC-EDITOR: The
name of the mailing list should be determined in consultation with
the IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Registration requests must be sent to the [TBD]@ietf.org mailing list
either approve or deny the registration request, communicating this for review and comment, with an appropriate subject (e.g., "Request
decision to the review list and IANA. Denials should include an for access token type: example"). [[ Note to RFC-EDITOR: The name of
explanation and, if applicable, suggestions as to how to make the the mailing list should be determined in consultation with the IESG
request successful. and IANA. Suggested name: oauth-ext-review. ]]
Decisions (or lack thereof) made by the Designated Expert(s) can be Within the review period, the Designated Expert(s) will either
first appealed to Security Area Directors (contactable using approve or deny the registration request, communicating this decision
app-ads@tools.ietf.org email address or directly by looking up their to the review list and IANA. Denials should include an explanation
email addresses on http://www.iesg.org/ website) and, if the and, if applicable, suggestions as to how to make the request
appellant is not satisfied with the response, to the full IESG (using successful.
the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA must only accept registry updates from the Designated Expert(s),
Expert(s), and should direct all requests for registration to the and should direct all requests for registration to the review mailing
review mailing list. list.
11.1.1. Registration Template 11.1.1. Registration Template
Type name: Type name:
The name requested (e.g., "example"). The name requested (e.g., "example").
Additional Token Endpoint Response Parameters: Additional Token Endpoint Response Parameters:
Additional response parameters returned together with the Additional response parameters returned together with the
"access_token" parameter. New parameters MUST be separately "access_token" parameter. New parameters MUST be separately
registered in the OAuth parameters registry as described by registered in the OAuth parameters registry as described by
Section 11.2. Section 11.2.
skipping to change at page 57, line 21 skipping to change at page 57, line 45
including a URI that can be used to retrieve a copy of the including a URI that can be used to retrieve a copy of the
document. An indication of the relevant sections may also be document. An indication of the relevant sections may also be
included, but is not required. included, but is not required.
11.2. The OAuth Parameters Registry 11.2. The OAuth Parameters Registry
This specification establishes the OAuth parameters registry. This specification establishes the OAuth parameters registry.
Additional parameters for inclusion in the authorization endpoint Additional parameters for inclusion in the authorization endpoint
request, the authorization endpoint response, the token endpoint request, the authorization endpoint response, the token endpoint
request, or the token endpoint response are registered on the advice request, or the token endpoint response are registered with a
of one or more Designated Experts (appointed by the IESG or their Specification Required ([RFC5226]) after a two weeks review period on
delegate), with a Specification Required (using terminology from the [TBD]@ietf.org mailing list, on the advice of one or more
[RFC5226]). However, to allow for the allocation of values prior to Designated Experts. However, to allow for the allocation of values
publication, the Designated Expert(s) may approve registration once prior to publication, the Designated Expert(s) may approve
they are satisfied that such a specification will be published. registration once they are satisfied that such a specification will
be published.
Registration requests should be sent to the [TBD]@ietf.org mailing
list for review and comment, with an appropriate subject (e.g.,
"Request for parameter: example"). [[ Note to RFC-EDITOR: The name of
the mailing list should be determined in consultation with the IESG
and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Registration requests must be sent to the [TBD]@ietf.org mailing list
either approve or deny the registration request, communicating this for review and comment, with an appropriate subject (e.g., "Request
decision to the review list and IANA. Denials should include an for parameter: example"). [[ Note to RFC-EDITOR: The name of the
explanation and, if applicable, suggestions as to how to make the mailing list should be determined in consultation with the IESG and
request successful. IANA. Suggested name: oauth-ext-review. ]]
Decisions (or lack thereof) made by the Designated Expert(s) can be Within the review period, the Designated Expert(s) will either
first appealed to Security Area Directors (contactable using approve or deny the registration request, communicating this decision
app-ads@tools.ietf.org email address or directly by looking up their to the review list and IANA. Denials should include an explanation
email addresses on http://www.iesg.org/ website) and, if the and, if applicable, suggestions as to how to make the request
appellant is not satisfied with the response, to the full IESG (using successful.
the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA must only accept registry updates from the Designated Expert(s),
Expert(s), and should direct all requests for registration to the and should direct all requests for registration to the review mailing
review mailing list. list.
11.2.1. Registration Template 11.2.1. Registration Template
Parameter name: Parameter name:
The name requested (e.g., "example"). The name requested (e.g., "example").
Parameter usage location: Parameter usage location:
The location(s) where parameter can be used. The possible The location(s) where parameter can be used. The possible
locations are: authorization request, authorization response, locations are: authorization request, authorization response,
token request, or token response. token request, or token response.
Change controller: Change controller:
skipping to change at page 60, line 22 skipping to change at page 60, line 38
o Parameter usage location: token request, token response o Parameter usage location: token request, token response
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
11.3. The OAuth Authorization Endpoint Response Type Registry 11.3. The OAuth Authorization Endpoint Response Type Registry
This specification establishes the OAuth authorization endpoint This specification establishes the OAuth authorization endpoint
response type registry. response type registry.
Additional response type for use with the authorization endpoint are Additional response type for use with the authorization endpoint are
registered on the advice of one or more Designated Experts (appointed registered with a Specification Required ([RFC5226]) after a two
by the IESG or their delegate), with a Specification Required (using weeks review period on the [TBD]@ietf.org mailing list, on the advice
terminology from [RFC5226]). However, to allow for the allocation of of one or more Designated Experts. However, to allow for the
values prior to publication, the Designated Expert(s) may approve allocation of values prior to publication, the Designated Expert(s)
registration once they are satisfied that such a specification will may approve registration once they are satisfied that such a
be published. specification will be published.
Registration requests should be sent to the [TBD]@ietf.org mailing
list for review and comment, with an appropriate subject (e.g.,
"Request for response type: example"). [[ Note to RFC-EDITOR: The
name of the mailing list should be determined in consultation with
the IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Registration requests must be sent to the [TBD]@ietf.org mailing list
either approve or deny the registration request, communicating this for review and comment, with an appropriate subject (e.g., "Request
decision to the review list and IANA. Denials should include an for response type: example"). [[ Note to RFC-EDITOR: The name of the
explanation and, if applicable, suggestions as to how to make the mailing list should be determined in consultation with the IESG and
request successful. IANA. Suggested name: oauth-ext-review. ]]
Decisions (or lack thereof) made by the Designated Expert(s) can be Within the review period, the Designated Expert(s) will either
first appealed to Security Area Directors (contactable using approve or deny the registration request, communicating this decision
app-ads@tools.ietf.org email address or directly by looking up their to the review list and IANA. Denials should include an explanation
email addresses on http://www.iesg.org/ website) and, if the and, if applicable, suggestions as to how to make the request
appellant is not satisfied with the response, to the full IESG (using successful.
the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA must only accept registry updates from the Designated Expert(s),
Expert(s), and should direct all requests for registration to the and should direct all requests for registration to the review mailing
review mailing list. list.
11.3.1. Registration Template 11.3.1. Registration Template
Response type name: Response type name:
The name requested (e.g., "example"). The name requested (e.g., "example").
Change controller: Change controller:
For standards-track RFCs, state "IETF". For others, give the name For standards-track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
e-mail address, home page URI) may also be included. e-mail address, home page URI) may also be included.
Specification document(s): Specification document(s):
skipping to change at page 61, line 38 skipping to change at page 61, line 46
o Response type name: token o Response type name: token
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
11.4. The OAuth Extensions Error Registry 11.4. The OAuth Extensions Error Registry
This specification establishes the OAuth extensions error registry. This specification establishes the OAuth extensions error registry.
Additional error codes used together with other protocol extensions Additional error codes used together with other protocol extensions
(i.e. extension grant types, access token types, or extension (i.e. extension grant types, access token types, or extension
parameters) are registered on the advice of one or more Designated parameters) are registered with a Specification Required ([RFC5226])
Experts (appointed by the IESG or their delegate), with a after a two weeks review period on the [TBD]@ietf.org mailing list,
Specification Required (using terminology from [RFC5226]). However, on the advice of one or more Designated Experts. However, to allow
to allow for the allocation of values prior to publication, the for the allocation of values prior to publication, the Designated
Designated Expert(s) may approve registration once they are satisfied Expert(s) may approve registration once they are satisfied that such
that such a specification will be published. a specification will be published.
Registration requests should be sent to the [TBD]@ietf.org mailing
list for review and comment, with an appropriate subject (e.g.,
"Request for error code: example"). [[ Note to RFC-EDITOR: The name
of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Registration requests must be sent to the [TBD]@ietf.org mailing list
either approve or deny the registration request, communicating this for review and comment, with an appropriate subject (e.g., "Request
decision to the review list and IANA. Denials should include an for error code: example"). [[ Note to RFC-EDITOR: The name of the
explanation and, if applicable, suggestions as to how to make the mailing list should be determined in consultation with the IESG and
request successful. IANA. Suggested name: oauth-ext-review. ]]
Decisions (or lack thereof) made by the Designated Expert(s) can be Within the review period, the Designated Expert(s) will either
first appealed to Security Area Directors (contactable using approve or deny the registration request, communicating this decision
app-ads@tools.ietf.org email address or directly by looking up their to the review list and IANA. Denials should include an explanation
email addresses on http://www.iesg.org/ website) and, if the and, if applicable, suggestions as to how to make the request
appellant is not satisfied with the response, to the full IESG (using successful.
the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA must only accept registry updates from the Designated Expert(s),
Expert(s), and should direct all requests for registration to the and should direct all requests for registration to the review mailing
review mailing list. list.
11.4.1. Registration Template 11.4.1. Registration Template
Error name: Error name:
The name requested (e.g., "example"). The name requested (e.g., "example").
Error usage location: Error usage location:
The location(s) where the error can be used. The possible The location(s) where the error can be used. The possible
locations are: authorization code grant error response locations are: authorization code grant error response
(Section 4.1.2.1), implicit grant error response (Section 4.1.2.1), implicit grant error response
(Section 4.2.2.1), or token error response (Section 5.2). (Section 4.2.2.1), or token error response (Section 5.2).
skipping to change at page 63, line 20 skipping to change at page 63, line 22
The OAuth WRAP specification was edited by Dick Hardt and authored by The OAuth WRAP specification was edited by Dick Hardt and authored by
Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom.
This specification is the work of the OAuth Working Group which This specification is the work of the OAuth Working Group which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
which shaped and formed the final specification: which shaped and formed the final specification:
Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
Bell, Brian Campbell, Scott Cantor, Marcos Caceres, Blaine Cook, Bell, Brian Campbell, Scott Cantor, Marcos Caceres, Blaine Cook,
Roger Crew, Brian Eaton, Leah Culver, Bill de hOra, Andre DeMarre, Roger Crew, Brian Eaton, Wesley Eddy, Leah Culver, Bill de hOra,
Brian Eaton, Wolter Eldering, Brian Ellin, Igor Faynberg, George Andre DeMarre, Brian Eaton, Wolter Eldering, Brian Ellin, Igor
Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, Brent Goldman, Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert,
Kristoffer Gronowski, Justin Hart, Dick Hardt, Craig Heath, Phil Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, Dick
Hunt, Michael B. Jones, Terry Jones, John Kemp, Mark Kent, Raffi Hardt, Craig Heath, Phil Hunt, Michael B. Jones, Terry Jones, John
Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui- Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf,
Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair
Manger, Mark McGloin, Laurence Miao, William Mills, Chuck Mortimore, Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William
Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin
Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu,
Vlad Skvortsov, Justin Smith, Haibin Song, Niv Steingarten, Christian Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song,
Stubner, Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Niv Steingarten, Christian Stubner, Jeremy Suriel, Paul Tarjan,
Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick
Skylar Woodward. Walker, Shane Weeden, and Skylar Woodward.
This document was produced under the chairmanship of Blaine Cook, This document was produced under the chairmanship of Blaine Cook,
Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area
directors included Lisa Dusseault, Peter Saint-Andre, and Stephen directors included Lisa Dusseault, Peter Saint-Andre, and Stephen
Farrell. Farrell.
Appendix A. Editor's Notes Appendix A. Editor's Notes
While many people contributed to this specification throughout its While many people contributed to this specification throughout its
long journey, the editor would like to acknowledge and thank a few long journey, the editor would like to acknowledge and thank a few
individuals for their outstanding and invaluable efforts leading up individuals for their outstanding and invaluable efforts leading up
to the publication of this specification. It is these individuals to the publication of this specification.
without whom this work would not have existed or reached its
successful conclusion.
David Recordon for continuously being one of OAuth's most valuable David Recordon for continuously being one of OAuth's most valuable
assets, bringing pragmatism and urgency to the work, and helping assets, bringing pragmatism and urgency to the work, and helping
shape it from its very beginning, as well as being one of the best shape it from its very beginning, as well as being one of the best
collaborators I had the pleasure of working with. collaborators I had the pleasure of working with.
James Manger for his creative ideas and always insightful feedback. James Manger for his creative ideas and always insightful feedback.
Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer, Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer,
Marius Scurtescu, and Luke Shepard for their continued participation Marius Scurtescu, and Luke Shepard for their continued participation
and valuable feedback. and valuable feedback.
 End of changes. 80 change blocks. 
232 lines changed or deleted 256 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/