< draft-ietf-oauth-v2-15.txt   draft-ietf-oauth-v2-16.txt >
Network Working Group E. Hammer-Lahav, Ed. Network Working Group E. Hammer-Lahav, Ed.
Internet-Draft Yahoo! Internet-Draft Yahoo!
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) D. Recordon
Intended status: Standards Track Facebook Intended status: Standards Track Facebook
Expires: October 8, 2011 D. Hardt Expires: November 20, 2011 D. Hardt
Microsoft Microsoft
April 6, 2011 May 19, 2011
The OAuth 2.0 Authorization Protocol The OAuth 2.0 Authorization Protocol
draft-ietf-oauth-v2-15 draft-ietf-oauth-v2-16
Abstract Abstract
The OAuth 2.0 authorization protocol enables granting third-party The OAuth 2.0 authorization protocol enables a third-party
applications limited access to HTTP service on behalf of an end-user application to obtain limited access to an HTTP service, either on
by orchestrating an approval interaction between the end-user and the behalf of an end-user by orchestrating an approval interaction
HTTP service. between the end-user and the HTTP service, or by allowing the third-
party application to obtain access on its own behalf.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 8, 2011. This Internet-Draft will expire on November 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 6 1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 7
1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Document Structure . . . . . . . . . . . . . . . . . . . . 10 1.6. Document Structure . . . . . . . . . . . . . . . . . . . 11
1.7. Notational Conventions . . . . . . . . . . . . . . . . . . 10 1.7. Notational Conventions . . . . . . . . . . . . . . . . . 11
2. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 10 2. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Authorization Endpoint . . . . . . . . . . . . . . . . . . 11 2.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 12
2.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 13
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 13 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 14
3.1. Client Password Authentication . . . . . . . . . . . . . . 14 3.1. Client Password Authentication . . . . . . . . . . . . . 15
3.2. Other Client Authentication Methods . . . . . . . . . . . 14 3.2. Other Client Authentication Methods . . . . . . . . . . . 16
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 15 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 16
4.1. Authorization Code . . . . . . . . . . . . . . . . . . . . 15 4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 16
4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 22
4.3. Resource Owner Password Credentials . . . . . . . . . . . 27 4.3. Resource Owner Password Credentials . . . . . . . . . . . 28
4.4. Client Credentials . . . . . . . . . . . . . . . . . . . . 29 4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 30
4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 32
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 32 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 33
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 32 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 33
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . . 33 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 34
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 35 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 36
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 36 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 37
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . . 36 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 38
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 37 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 38
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . . 37 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 39
8.3. Defining New Authorization Grant Types . . . . . . . . . . 38 8.3. Defining New Authorization Grant Types . . . . . . . . . 39
8.4. Defining Additional Error Codes . . . . . . . . . . . . . 38 8.4. Defining Additional Error Codes . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10.1. The OAuth Access Token Type Registry . . . . . . . . . . . 39 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 42
10.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 40 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 42
10.3. The OAuth Extensions Error Registry . . . . . . . . . . . 43 10.3. Access Token Credentials . . . . . . . . . . . . . . . . 43
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 45 10.5. Request Confidentiality . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.6. Endpoints Authenticity . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.7. Credentials Guessing Attacks . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 46 10.8. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 10.9. Authorization Codes . . . . . . . . . . . . . . . . . . . 45
10.10. Session Fixation . . . . . . . . . . . . . . . . . . . . 45
10.11. Redirection URI Validation . . . . . . . . . . . . . . . 46
10.12. Resource Owner Password Credentials . . . . . . . . . . . 46
10.13. XSRF/CSRF Prevention . . . . . . . . . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 46
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 48
11.3. The OAuth Extensions Error Registry . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
accesses a protected resource on the server by authenticating with accesses a protected resource on the server by authenticating with
the server using the resource owner's credentials. In order to the server using the resource owner's credentials. In order to
provide third-party applications access to protected resources, the provide third-party applications access to protected resources, the
resource owner shares its credentials with the third-party. This resource owner shares its credentials with the third-party. This
creates several problems and limitations: creates several problems and limitations:
skipping to change at page 6, line 45 skipping to change at page 7, line 45
implicit, resource owner password credentials, and client implicit, resource owner password credentials, and client
credentials, as well as an extensibility mechanism for defining credentials, as well as an extensibility mechanism for defining
additional types. additional types.
1.4.1. Authorization Code 1.4.1. Authorization Code
The authorization code is obtained by using an authorization server The authorization code is obtained by using an authorization server
as an intermediary between the client and resource owner. Instead of as an intermediary between the client and resource owner. Instead of
requesting authorization directly from the resource owner, the client requesting authorization directly from the resource owner, the client
directs the resource owner to an authorization server (via its user- directs the resource owner to an authorization server (via its user-
agent as defined in [RFC2616]), which in turns directs the resource agent as defined in [RFC2616]), which in turn directs the resource
owner back to the client with the authorization code. owner back to the client with the authorization code.
Before directing the resource owner back to the client with the Before directing the resource owner back to the client with the
authorization code, the authorization server authenticates the authorization code, the authorization server authenticates the
resource owner and obtains authorization. Because the resource owner resource owner and obtains authorization. Because the resource owner
only authenticates with the authorization server, the resource only authenticates with the authorization server, the resource
owner's credentials are never shared with the client. owner's credentials are never shared with the client.
The authorization code provides a few important security benefits The authorization code provides a few important security benefits
such as the ability to authenticate the client and issuing the access such as the ability to authenticate the client and issuing the access
skipping to change at page 11, line 32 skipping to change at page 12, line 32
The means through which the client obtains the location of the The means through which the client obtains the location of the
authorization endpoint are beyond the scope of this specification but authorization endpoint are beyond the scope of this specification but
is typically provided in the service documentation. The endpoint URI is typically provided in the service documentation. The endpoint URI
MAY include a query component as defined by [RFC3986] section 3, MAY include a query component as defined by [RFC3986] section 3,
which MUST be retained when adding additional query parameters. which MUST be retained when adding additional query parameters.
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 the use of a HTTP response), the authorization server MUST require the use of a
transport-layer security mechanism when sending requests to the token transport-layer security mechanism when sending requests to the
endpoints. The authorization server MUST support TLS 1.2 as defined authorization endpoint. The authorization server MUST support TLS
in [RFC5246], and MAY support additional transport-layer mechanisms 1.2 as defined in [RFC5246], and MAY support additional transport-
meeting its security requirements. layer mechanisms meeting its security requirements.
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.
The REQUIRED "response_type" request parameter is used to identify The REQUIRED "response_type" request parameter is used to identify
which grant type the client is requesting: authorization code or which grant type the client is requesting: authorization code or
implicit, described in Section 4.1.1 and Section 4.2.1 respectively. implicit, described in Section 4.1.1 and Section 4.2.1 respectively.
If the request is missing the "response_type" parameter, the If the request is missing the "response_type" parameter, the
authorization server SHOULD return an error response as described in authorization server SHOULD return an error response as described in
skipping to change at page 12, line 49 skipping to change at page 13, line 49
The means through which the client obtains the location of the token The means through which the client obtains the location of the token
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. The endpoint URI MAY include provided in the service documentation. The endpoint URI MAY include
a query component, which MUST be retained when adding additional a query component, which MUST be retained when adding additional
query parameters. query parameters.
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 the use of a transport-layer authorization server MUST require the use of a transport-layer
security mechanism when sending requests to the token endpoints. The security mechanism when sending requests to the token endpoint. The
authorization server MUST support TLS 1.2 as defined in [RFC5246], authorization server MUST support TLS 1.2 as defined in [RFC5246],
and MAY support additional transport-layer mechanisms meeting its and MAY support additional transport-layer mechanisms meeting its
security requirements. security requirements.
The token endpoint requires client authentication as described in The token endpoint requires client authentication as described in
Section 3. The authorization server MAY accept any form of client Section 3. The authorization server MAY accept any form of client
authentication meeting its security requirements. The client MUST authentication meeting its security requirements. The client MUST
NOT use more than one authentication method in each request. NOT use more than one authentication method in each request.
The client MUST use the HTTP "POST" method when making access token The client MUST use the HTTP "POST" method when making access token
skipping to change at page 13, line 34 skipping to change at page 14, line 34
The client credentials include a client identifier - a unique string The client credentials include a client identifier - a unique string
issued to the client to identify itself to the authorization server. issued to the client to identify itself to the authorization server.
The client identifier is not a secret, it is exposed to the resource The client identifier is not a secret, it is exposed to the resource
owner, and MUST NOT be used alone for client authentication. Client owner, and MUST NOT be used alone for client authentication. Client
authentication is accomplished via additional means such as a authentication is accomplished via additional means such as a
matching client password. matching client password.
The methods through which the client obtains its client credentials The methods through which the client obtains its client credentials
are beyond the scope of this specification. However, the client are beyond the scope of this specification. However, the client
registration process typically includes gathering relevant registration process typically includes gathering relevant
information used to inform the resource owner about the client when information which is used to educate the resource owner about the
requesting authorization. client when requesting authorization.
Due to the nature of some clients, the authorization server should Due to the nature of some clients, the authorization server should
not make assumptions about the confidentiality of client credentials not make assumptions about the confidentiality of client credentials
without establishing trust with the client. The authorization server without establishing trust with the client. The authorization server
SHOULD NOT issue client credentials to clients incapable of keeping SHOULD NOT issue client credentials to clients incapable of keeping
their credentials confidential (typically determined during the their credentials confidential (typically determined during the
client registration process). client registration process).
In addition, the authorization server MAY allow unauthenticated In addition, the authorization server MAY allow unauthenticated
access token requests when the client identity does not matter (e.g. access token requests when the client identity does not matter (e.g.
anonymous client) or when the client identity is established via anonymous client) or when the client identity is established via
other means. For readability purposes only, this specification is other means. For readability purposes only, this specification is
written under the assumption that the authorization server requires written under the assumption that the authorization server requires
some form of client authentication. However, such language does not some form of client authentication. However, such language does not
affect the authorization server's discretion in allowing affect the authorization server's discretion in allowing
unauthenticated client requests. unauthenticated client requests.
3.1. Client Password Authentication 3.1. Client Password Authentication
The client password authentication uses a shared symmetric secret to [[ Pending Consensus ]]
authenticate the client. The client identifier and password are
included in the request using the following parameters:
client_id Clients in possession of client password credentials (the client
REQUIRED. The client identifier. identifier together with a shared symmetric secret) MAY use the HTTP
client_secret Basic authentication scheme as defined in [RFC2617] to authenticate
REQUIRED. The client password. with the authorization server. The client identifier is used as the
username, and the secret is used as the password.
For example (line breaks are for display purposes only): When using the HTTP Basic authentication scheme, the client
identifier is included twice in the request (in the "Authorization"
header and in the "client_id" parameter). The authorization server
MUST ensure the two identifiers belong to the same client.
For example (extra line breaks are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3& grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1& code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
3.2. Other Client Authentication Methods Alternatively, the authorization server MAY allow including the
client secret in the request body using the following parameter:
In cases where client password authentication is not suitable or client_secret
sufficient, the authorization server MAY support other existing HTTP REQUIRED. The client secret.
authentication schemes or define new methods.
For example, the authorization server MAY support using the HTTP The use of the "client_secret" parameter is NOT RECOMMENDED, and
Basic authentication scheme as defined in [RFC2617] to include the should be limited to clients unable to directly utilize the HTTP
client identifier as the username and client password as the password Basic authentication scheme.
(line breaks are for display purposes only):
For example (extra line breaks are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=i1WsRn1uB1& grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
When using a method other than client password authentication to Since requests using this authentication method result in the
exchange an authorization code grant type, the authorization server transmission of clear-text credentials, the authorization server MUST
MUST define a method for mapping the client credentials to the client require the use of a transport-layer security mechanism when sending
identifier used to obtain the authorization code. requests to the token endpoint.
3.2. Other Client Authentication Methods
The authorization server MAY support any suitable HTTP authentication
scheme matching its security requirements. When using other
authentication methods, the authorization server MUST define a
mapping between the client identifier and the credentials used to
authenticate.
4. Obtaining Authorization 4. Obtaining Authorization
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner. The authorization is expressed in the form of an resource owner. The authorization is expressed in the form of an
authorization grant which the client uses to request the access authorization grant which the client uses to request the access
token. OAuth defines four grant types: authorization code, implicit, token. OAuth defines four grant types: authorization code, implicit,
resource owner password credentials, and client credentials. It also resource owner password credentials, and client credentials. It also
provides an extension mechanism for defining additional grant types. provides an extension mechanism for defining additional grant types.
skipping to change at page 17, line 48 skipping to change at page 18, line 48
OPTIONAL. An opaque value used by the client to maintain state OPTIONAL. An opaque value used by the client to maintain state
between the request and callback. The authorization server between the request and callback. The authorization server
includes this value when redirecting the user-agent back to the includes this value when redirecting the user-agent back to the
client. client.
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the HTTP redirection response, or by other means available to it via the
user-agent. user-agent.
For example, the client directs the user-agent to make the following For example, the client directs the user-agent to make the following
HTTP request using transport-layer security (line breaks are for HTTP request using transport-layer security (extra line breaks are
display purposes only): for display purposes only):
GET /authorize?response_type=code&client_id=s6BhdRkqt3& GET /authorize?response_type=code&client_id=s6BhdRkqt3&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com Host: server.example.com
The authorization server validates the request to ensure all required The authorization server validates the request to ensure all required
parameters are present and valid. If the request is valid, the parameters are present and valid. If the request is valid, the
authorization server authenticates the resource owner and obtains an authorization server authenticates the resource owner and obtains an
authorization decision (by asking the resource owner or by authorization decision (by asking the resource owner or by
establishing approval via other means). establishing approval via other means).
skipping to change at page 19, line 37 skipping to change at page 20, line 37
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.
a 4xx or 5xx HTTP status code (except for 400 and 401) a 4xx or 5xx HTTP status code (except for 400 and 401)
[[ Pending Consensus ]] The authorization server MAY set The authorization server MAY set the "error" parameter
the "error" parameter value to a numerical HTTP status value to a numerical HTTP status code from the 4xx or 5xx
code from the 4xx or 5xx range, with the exception of the range, with the exception of the 400 (Bad Request) and
400 (Bad Request) and 401 (Unauthorized) status codes. 401 (Unauthorized) status codes. For example, if the
For example, if the service is temporarily unavailable, service is temporarily unavailable, the authorization
the authorization server MAY return an error response server MAY return an error response with "error" set to
with "error" set to "503". "503".
error_description error_description
OPTIONAL. A human-readable text providing additional OPTIONAL. A human-readable text providing additional
information, used to assist in the understanding and resolution information, used to assist in the understanding and resolution
of the error occurred. of the error occurred. [[ add language and encoding information
]]
error_uri error_uri
OPTIONAL. A URI identifying a human-readable web page with OPTIONAL. A URI identifying a human-readable web page with
information about the error, used to provide the resource owner information about the error, used to provide the resource owner
with additional information about the error. with additional information about the error.
state state
REQUIRED if a valid "state" parameter was present in the client REQUIRED if a valid "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. Set to the exact value received from
the client. the client.
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?error=access_denied Location: https://client.example.com/cb?error=access_denied
4.1.3. Access Token Request 4.1.3. Access Token Request
The client makes a request to the token endpoint by adding the The client makes a request to the token endpoint by adding the
following parameter using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format in the HTTP request entity-body: format in the HTTP request entity-body:
grant_type grant_type
REQUIRED. Value MUST be set to "authorization_code". REQUIRED. Value MUST be set to "authorization_code".
client_id
REQUIRED. The client identifier as described in Section 3.
code code
REQUIRED. The authorization code received from the REQUIRED. The authorization code received from the
authorization server. authorization server.
redirect_uri redirect_uri
REQUIRED. The redirection URI used by the authorization server REQUIRED. The redirection URI used by the authorization server
to return the authorization response in the previous step. to return the authorization response in the previous step.
The client includes its authentication credentials as described in The client includes its authentication credentials as described in
Section 3 Section 3
For example, the client makes the following HTTP request by including For example, the client makes the following HTTP using transport-
its client credentials via the "client_id" and "client_secret" layer security (extra line breaks are for display purposes only):
parameters, and using transport-layer security (line breaks are for
display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3& grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1& code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST: The authorization server MUST:
o Validate the client credentials and ensure that the authorization o Validate the client credentials and ensure that the authorization
code was issued to that client. code was issued to that client.
o Verify that the authorization code is valid, and that the o Verify that the authorization code is valid, and that the
redirection URI matches the redirection URI used by the redirection URI matches the redirection URI used by the
authorization server to deliver the authorization code. authorization server to deliver the authorization code.
skipping to change at page 24, line 16 skipping to change at page 25, line 16
OPTIONAL. An opaque value used by the client to maintain state OPTIONAL. An opaque value used by the client to maintain state
between the request and callback. The authorization server between the request and callback. The authorization server
includes this value when redirecting the user-agent back to the includes this value when redirecting the user-agent back to the
client. client.
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the HTTP redirection response, or by other means available to it via the
user-agent. user-agent.
For example, the client directs the user-agent to make the following For example, the client directs the user-agent to make the following
HTTP request using transport-layer security (line breaks are for HTTP request using transport-layer security (extra line breaks are
display purposes only): for display purposes only):
GET /authorize?response_type=token&client_id=s6BhdRkqt3& GET /authorize?response_type=token&client_id=s6BhdRkqt3&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com Host: server.example.com
The authorization server validates the request to ensure all required The authorization server validates the request to ensure all required
parameters are present and valid. If the request is valid, the parameters are present and valid. If the request is valid, the
authorization server authenticates the resource owner and obtains an authorization server authenticates the resource owner and obtains an
authorization decision (by asking the resource owner or by authorization decision (by asking the resource owner or by
establishing approval via other means). establishing approval via other means).
skipping to change at page 25, line 20 skipping to change at page 26, line 20
and each string adds an additional access range to the and each string adds an additional access range to the
requested scope. The authorization server SHOULD include the requested scope. The authorization server SHOULD include the
parameter if the requested scope is different from the one parameter if the requested scope is different from the one
requested by the client. requested by the client.
state state
REQUIRED if the "state" parameter was present in the client REQUIRED if the "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. Set to the exact value received from
the client. the client.
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 (URI line breaks are for display sending the following HTTP response (URI extra line breaks are for
purposes only): display purposes only):
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: http://example.com/rd#access_token=FJQbwq9& Location: http://example.com/rd#access_token=FJQbwq9&
token_type=example&expires_in=3600 token_type=example&expires_in=3600
The client SHOULD ignore unrecognized response parameters. The The client SHOULD ignore unrecognized response parameters. The
access token string size is left undefined by this specification. access token string size is left undefined by this specification.
The client should avoid making assumptions about value sizes. The 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.
skipping to change at page 26, line 21 skipping to change at page 27, line 21
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
The requested scope is invalid, unknown, or malformed. The requested scope is invalid, unknown, or malformed.
a 4xx or 5xx HTTP status code (except for 400 and 401) a 4xx or 5xx HTTP status code (except for 400 and 401)
[[ Pending Consensus ]] The authorization server MAY set The authorization server MAY set the "error" parameter
the "error" parameter value to a numerical HTTP status value to a numerical HTTP status code from the 4xx or 5xx
code from the 4xx or 5xx range, with the exception of the range, with the exception of the 400 (Bad Request) and
400 (Bad Request) and 401 (Unauthorized) status codes. 401 (Unauthorized) status codes. For example, if the
For example, if the service is temporarily unavailable, service is temporarily unavailable, the authorization
the authorization server MAY return an error response server MAY return an error response with "error" set to
with "error" set to "503". "503".
error_description error_description
OPTIONAL. A human-readable text providing additional OPTIONAL. A human-readable text providing additional
information, used to assist in the understanding and resolution information, used to assist in the understanding and resolution
of the error occurred. of the error occurred. [[ add language and encoding information
]]
error_uri error_uri
OPTIONAL. A URI identifying a human-readable web page with OPTIONAL. A URI identifying a human-readable web page with
information about the error, used to provide the resource owner information about the error, used to provide the resource owner
with additional information about the error. with additional information about the error.
state state
REQUIRED if a valid "state" parameter was present in the client REQUIRED if a valid "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. Set to the exact value received from
the client. the client.
For example, the authorization server redirects the user-agent by For example, the authorization server redirects the user-agent by
skipping to change at page 28, line 18 skipping to change at page 29, line 18
4.3.1. Authorization Request and Response 4.3.1. Authorization Request and Response
The method through which the client obtains the resource owner The method through which the client obtains the resource owner
credentials is beyond the scope of this specification. The client credentials is beyond the scope of this specification. The client
MUST discard the credentials once an access token has been obtained. MUST discard the credentials once an access token has been obtained.
4.3.2. Access Token Request 4.3.2. Access Token Request
The client makes a request to the token endpoint by adding the The client makes a request to the token endpoint by adding the
following parameter using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format in the HTTP request entity-body: format in the HTTP request entity-body:
grant_type grant_type
REQUIRED. Value MUST be set to "password". REQUIRED. Value MUST be set to "password".
client_id
REQUIRED. The client identifier as described in Section 3.
username username
REQUIRED. The resource owner username. REQUIRED. The resource owner username, encoded as UTF-8.
password password
REQUIRED. The resource owner password. REQUIRED. The resource owner password, encoded as UTF-8.
scope scope
OPTIONAL. The scope of the access request expressed as a list OPTIONAL. The scope of the access request expressed as a list
of space-delimited, case sensitive strings. The value is of space-delimited, case sensitive strings. The value is
defined by the authorization server. If the value contains defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter, multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the and each string adds an additional access range to the
requested scope. requested scope.
The client includes its authentication credentials as described in The client includes its authentication credentials as described in
Section 3 Section 3
For example, the client makes the following HTTP request by including For example, the client makes the following HTTP request using
its client credentials via the "client_id" and "client_secret" transport-layer security (extra line breaks are for display purposes
parameters, and using transport-layer security (line breaks are for only):
display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=password&client_id=s6BhdRkqt3& grant_type=password&client_id=s6BhdRkqt3&
client_secret=47HDu8s&username=johndoe&password=A3ddj3w username=johndoe&password=A3ddj3w
The authorization server MUST: The authorization server MUST:
o Validate the client credentials. o Validate the client credentials.
o Validate the resource owner password credentials. o Validate the resource owner password credentials.
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 30, line 19 skipping to change at page 31, line 21
4.4.1. Authorization Request and Response 4.4.1. Authorization Request and Response
Since the client credentials are used as the authorization grant, no Since the client credentials are used as the authorization grant, no
additional authorization request is needed as the client is already additional authorization request is needed as the client is already
in the possession of its client credentials. in the possession of its client credentials.
4.4.2. Access Token Request 4.4.2. Access Token Request
The client makes a request to the token endpoint by adding the The client makes a request to the token endpoint by adding the
following parameter using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format in the HTTP request entity-body: format in the HTTP request entity-body:
grant_type grant_type
REQUIRED. Value MUST be set to "client_credentials". REQUIRED. Value MUST be set to "client_credentials".
client_id
REQUIRED. The client identifier as described in Section 3.
scope scope
OPTIONAL. The scope of the access request expressed as a list OPTIONAL. The scope of the access request expressed as a list
of space-delimited, case sensitive strings. The value is of space-delimited, case sensitive strings. The value is
defined by the authorization server. If the value contains defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter, multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the and each string adds an additional access range to the
requested scope. requested scope.
The client includes its authentication credentials as described in The client includes its authentication credentials as described in
Section 3 Section 3
For example, the client makes the following HTTP request by including For example, the client makes the following HTTP request using
its client credentials via the "client_id" and "client_secret" transport-layer security (extra line breaks are for display purposes
parameters, and using transport-layer security (line breaks are for only):
display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=s6BhdRkqt3& grant_type=client_credentials&client_id=s6BhdRkqt3
client_secret=47HDu8s
The authorization server MUST validate the client credentials. The authorization server MUST validate the client credentials.
4.4.3. Access Token Response 4.4.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
token as described in Section 5.1. If the request failed client token as described in Section 5.1. If the request failed client
authentication or is invalid, the authorization server returns an authentication or is invalid, the authorization server returns an
error response as described in Section 5.2. error response as described in Section 5.2.
skipping to change at page 32, line 5 skipping to change at page 32, line 47
breaks are for display purposes only): breaks are for display purposes 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 Content-Type: application/x-www-form-urlencoded
grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F
saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ
[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh
token as described in Section 5.1. If the request failed client
authentication or is invalid, the authorization server returns an
error response as described in Section 5.2.
5. Issuing an Access Token 5. Issuing an Access Token
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
token as described in Section 5.1. If the request failed client token as described in Section 5.1. If the request failed client
authentication or is invalid, the authorization server returns an authentication or is invalid, the authorization server returns an
error response as described in Section 5.2. error response as described in Section 5.2.
5.1. Successful Response 5.1. Successful Response
skipping to change at page 34, line 4 skipping to change at page 35, line 9
client credentials included, multiple client credentials client credentials included, multiple client credentials
included, or unsupported credentials type). The included, or unsupported credentials type). The
authorization server MAY return an HTTP 401 authorization server MAY return an HTTP 401
(Unauthorized) status code to indicate which HTTP (Unauthorized) status code to indicate which HTTP
authentication schemes are supported. If the client authentication schemes are supported. If the client
attempted to authenticate via the "Authorization" request attempted to authenticate via the "Authorization" request
header field, the authorization server MUST respond with header field, the authorization server MUST respond with
an HTTP 401 (Unauthorized) status code, and include the an HTTP 401 (Unauthorized) status code, and include the
"WWW-Authenticate" response header field matching the "WWW-Authenticate" response header field matching the
authentication scheme used by the client. authentication scheme used by the client.
invalid_grant invalid_grant
The provided authorization grant is invalid, expired, The provided authorization grant is invalid, expired,
revoked, does not match the redirection URI used in the revoked, does not match the redirection URI used in the
authorization request, or was issued to another client. authorization request, or was issued to another client.
unauthorized_client unauthorized_client
The authenticated client is not authorized to use this The authenticated client is not authorized to use this
authorization grant type. authorization grant type.
unsupported_grant_type unsupported_grant_type
The authorization grant type is not supported by the The authorization grant type is not supported by the
authorization server. authorization server.
invalid_scope invalid_scope
The requested scope is invalid, unknown, malformed, or The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner. exceeds the scope granted by the resource owner.
error_description error_description
OPTIONAL. A human-readable text providing additional OPTIONAL. A human-readable text providing additional
information, used to assist in the understanding and resolution information, used to assist in the understanding and resolution
of the error occurred. of the error occurred. [[ add language and encoding information
]]
error_uri error_uri
OPTIONAL. A URI identifying a human-readable web page with OPTIONAL. A URI identifying a human-readable web page with
information about the error, used to provide the resource owner information about the error, used to provide the resource owner
with additional information about the error. with additional information about the error.
The parameters are included in the entity body of the HTTP response The parameters are included in the entity body of the HTTP response
using the "application/json" media type as defined by [RFC4627]. The using the "application/json" media type as defined by [RFC4627]. The
parameters are serialized into a JSON structure by adding each parameters are serialized into a JSON structure by adding each
parameter at the highest structure level. Parameter names and string parameter at the highest structure level. Parameter names and string
values are included as JSON strings. Numerical values are included values are included as JSON strings. Numerical values are included
skipping to change at page 34, line 44 skipping to change at page 35, line 49
For example: For example:
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"error":"invalid_request" "error":"invalid_request"
} }
[[ Pending Consensus ]] If the authorization server encounters an If the authorization server encounters an error condition other than
error condition other than the 400 (Bad Request) and 401 the 400 (Bad Request) and 401 (Unauthorized) responses described
(Unauthorized) responses described above (e.g. the service is above (e.g. the service is temporarily unavailable), the
temporarily unavailable), the authorization server SHOULD include an authorization server SHOULD include an error response in the entity
error response in the entity body, and set the "error" parameter body, and set the "error" parameter value to the numerical HTTP
value to the numerical HTTP status code returned. status code returned.
For example: For example:
HTTP/1.1 503 Service Unavailable HTTP/1.1 503 Service Unavailable
Content-Type: application/json Content-Type: application/json
{ {
"error":"503" "error":"503"
} }
6. Refreshing an Access Token 6. Refreshing an Access Token
The client makes a request to the token endpoint by adding the If the authorization server issued a refresh token to the client, the
following parameter using the "application/x-www-form-urlencoded" client makes a refresh request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded"
format in the HTTP request entity-body: format in the HTTP request entity-body:
grant_type grant_type
REQUIRED. Value MUST be set to "refresh_token". REQUIRED. Value MUST be set to "refresh_token".
client_id
REQUIRED. The client identifier as described in Section 3.
refresh_token refresh_token
REQUIRED. The refresh token issued to the client. REQUIRED. The refresh token issued to the client.
scope scope
OPTIONAL. The scope of the access request expressed as a list OPTIONAL. The scope of the access request expressed as a list
of space-delimited, case sensitive strings. The value is of space-delimited, case sensitive strings. The value is
defined by the authorization server. If the value contains defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter, multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the and each string adds an additional access range to the
requested scope. The requested scope MUST be equal or lesser requested scope. The requested scope MUST be equal or lesser
than the scope originally granted by the resource owner, and if than the scope originally granted by the resource owner, and if
omitted is treated as equal to the scope originally granted by omitted is treated as equal to the scope originally granted by
the resource owner. the resource owner.
The client includes its authentication credentials as described in The client includes its authentication credentials as described in
Section 3. Section 3.
For example, the client makes the following HTTP request by including For example, the client makes the following HTTP request using
its client credentials via the "client_id" and "client_secret" transport-layer security (extra line breaks are for display purposes
parameters, and using transport-layer security (line breaks are for only):
display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&client_id=s6BhdRkqt3& grant_type=refresh_token&client_id=s6BhdRkqt3&
client_secret=8eSEIpnqmM&refresh_token=n4E9O119d refresh_token=n4E9O119d
The authorization server MUST validate the client credentials, ensure The authorization server MUST validate the client credentials, ensure
that the refresh token was issued to the authenticated client, that the refresh token was issued to the authenticated client,
validate the refresh token, and verify that the resource owner's validate the refresh token, and verify that the resource owner's
authorization is still valid. If valid and authorized, the authorization is still valid. If valid and authorized, the
authorization server issues an access token as described in authorization server issues an access token as described in
Section 5.1. If the request failed verification or is invalid, the Section 5.1. If the request failed verification or is invalid, the
authorization server returns an error response as described in authorization server returns an error response as described in
Section 5.2. Section 5.2.
skipping to change at page 36, line 39 skipping to change at page 38, line 9
The method in which the client utilized the access token to The method in which the client utilized the access token to
authenticate with the resource server depends on the type of access authenticate with the resource server depends on the type of access
token issued by the authorization server. Typically, it involves token issued by the authorization server. Typically, it involves
using the HTTP "Authorization" request header field [RFC2617] with an using the HTTP "Authorization" request header field [RFC2617] with an
authentication scheme defined by the access token type specification. authentication scheme defined by the access token type specification.
7.1. Access Token Types 7.1. Access Token Types
The access token type provides the client with the information The access token type provides the client with the information
required to successfully utilize the access token to make a protected required to successfully utilize the access token to make a protected
resource request (along with type-specific attributes). resource request (along with type-specific attributes). The client
MUST NOT use an access token if it does not understand the token
type.
For example, the "bearer" token type defined in For example, the "bearer" token type defined in
[I-D.ietf-oauth-v2-bearer] is utilized by simply including the access [I-D.ietf-oauth-v2-bearer] is utilized by simply including the access
token string in the request: token string in the request:
GET /resource/1 HTTP/1.1 GET /resource/1 HTTP/1.1
Host: example.com Host: example.com
Authorization: Bearer h480djs93hd8 Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
while the "mac" token type defined in [I-D.hammer-oauth-v2-mac-token] while the "mac" token type defined in [I-D.ietf-oauth-v2-http-mac] is
is utilized by issuing a token secret together with the access token utilized by issuing a MAC key together with the access token which is
which is used to sign certain components of the HTTP requests: used to sign certain components of the HTTP requests:
GET /resource/1 HTTP/1.1 GET /resource/1 HTTP/1.1
Host: example.com Host: example.com
Authorization: MAC token="h480djs93hd8", Authorization: MAC id="h480djs93hd8",
timestamp="137131200", nonce="274312:dj83hs9s",
nonce="dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
signature="kDZvddkndxvhGRXZhvuDjEWhGeE="
The above examples are provided for illustration purposes only.
Developers are advised to consult the [I-D.ietf-oauth-v2-bearer] and
[I-D.ietf-oauth-v2-http-mac] specifications before use.
Each access token type definition specifies the additional attributes Each access token type definition specifies the additional attributes
(if any) sent to the client together with the "access_token" response (if any) sent to the client together with the "access_token" response
parameter. It also defines the HTTP authentication method used to parameter. It also defines the HTTP authentication method used to
include the access token when making a protected resource request. include the access token when making a protected resource request.
8. Extensibility 8. Extensibility
8.1. Defining Access Token Types 8.1. Defining Access Token Types
Access token types can be defined in one of two ways: registered in Access token types can be defined in one of two ways: registered in
the access token type registry (following the procedures in the access token type registry (following the procedures in
Section 10.1), or use a unique absolute URI as its name. Section 11.1), or use a unique absolute URI as its name.
Types utilizing a URI name SHOULD be limited to vendor-specific Types utilizing a URI name SHOULD be limited to vendor-specific
implementations that are not commonly applicable, and are specific to implementations that are not commonly applicable, and are specific to
the implementation details of the resource server where they are the implementation details of the resource server where they are
used. used.
All other types MUST be registered. Type names MUST conform to the All other types MUST be registered. Type names MUST conform to the
type-name ABNF. If the type definition includes a new HTTP type-name ABNF. If the type definition includes a new HTTP
authentication scheme, the type name SHOULD be identical to the HTTP authentication scheme, the type name SHOULD be identical to the HTTP
authentication scheme name (as defined by [RFC2617]). authentication scheme name (as defined by [RFC2617]).
type-name = 1*name-char type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA name-char = "-" / "." / "_" / DIGIT / ALPHA
8.2. Defining New Endpoint Parameters 8.2. Defining New Endpoint Parameters
New request or response parameters for use with the authorization New request or response parameters for use with the authorization
endpoint or the token endpoint are defined and registered in the endpoint or the token endpoint are defined and registered in the
parameters registry following the procedure in Section 10.2. parameters registry following the procedure in Section 11.2.
Parameter names MUST conform to the param-name ABNF and parameter Parameter names MUST conform to the param-name ABNF and parameter
values syntax MUST be well-defined (e.g., using ABNF, or a reference values syntax MUST be well-defined (e.g., using ABNF, or a reference
to the syntax of an existing parameter). to the syntax of an existing parameter).
param-name = 1*name-char param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA name-char = "-" / "." / "_" / DIGIT / ALPHA
Unregistered vendor-specific parameter extensions that are not Unregistered vendor-specific parameter extensions that are not
commonly applicable, and are specific to the implementation details commonly applicable, and are specific to the implementation details
of the authorization server where they are used SHOULD utilize a of the authorization server where they are used SHOULD utilize a
vendor-specific prefix that is not likely to conflict with other vendor-specific prefix that is not likely to conflict with other
registered values (e.g. begin with 'companyname_'). registered values (e.g. begin with 'companyname_').
8.3. Defining New Authorization Grant Types 8.3. Defining New Authorization Grant Types
New authorization grant types can be defined by assigning them a New authorization grant types can be defined by assigning them a
unique absolute URI for use with the "grant_type" parameter. If the unique absolute URI for use with the "grant_type" parameter. If the
extension grant type requires additional token endpoint parameters, extension grant type requires additional token endpoint parameters,
they MUST be registered in the OAuth parameters registry as described they MUST be registered in the OAuth parameters registry as described
by Section 10.2. by Section 11.2.
8.4. Defining Additional Error Codes 8.4. Defining Additional Error Codes
[[ Pending Consensus ]]
In cases where protocol extensions (i.e. access token types, In cases where protocol extensions (i.e. access token types,
extension parameters, or extension grant types) require additional extension parameters, or extension grant types) require additional
error codes to be used with the authorization code grant error error codes to be used with the authorization code grant error
response (Section 4.1.2.1), the implicit grant error response response (Section 4.1.2.1), the implicit grant error response
(Section 4.2.2.1), or the token error response (Section 5.2), such (Section 4.2.2.1), or the token error response (Section 5.2), such
error codes MAY be defined. error codes MAY be defined.
Extension error codes MUST be registered (following the procedures in Extension error codes MUST be registered (following the procedures in
Section 10.3) if the extension they are used in conjunction with is Section 11.3) if the extension they are used in conjunction with is a
registered. Additional error codes used with unregistered extensions registered access token type, a registered endpoint parameter, or an
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. Security Considerations 9. Native Applications
[[ TBD ]] [[ Pending consensus ]]
10. IANA Considerations A native application is a client which is installed and executes on
the end-user's device (i.e. desktop application, native mobile
application). Native applications are often capable of interacting
with (or embedding) a user-agent but are limited in how such
interactions affects their overall end-user experience. In many
cases, native applications are incapable of receiving redirection
requests from the authorization server (e.g. due to firewall rules,
operating system restrictions).
10.1. The OAuth Access Token Type Registry Native applications can utilize OAuth in different ways, based on
their requirements and desired end-user experience:
o Use the authorization code grant type flow described in
Section 4.1 by launching an external user-agent. The native
application can capture the response by providing a redirection
URI identifying a local (non-network) resource (registered with
the operating system to invoke the native application as handler),
or by providing a redirection URI identifying a server-hosted
resource under the native application's control, which in turn
makes the response available to the native application (e.g. using
the user-agent window title or other locations accessible from
outside the user-agent).
o Use the authorization code grant type flow described in
Section 4.1 by embedding a user-agent. The native application
obtains the response by directly communicating with the embedded
user-agent. Embedded user-agents are discouraged as they
typically provide a less consistent user experience and do not
enable the end-user to verify the authorization server's
authenticity.
Native applications SHOULD use the authorization code grant type flow
without client password credentials (due to their inability to keep
the credentials confidential) to obtain short-lived access tokens,
and use refresh tokens to maintain access.
When choosing between launching an external user-agent and an
embedding a user-agent, native application developers should consider
the following:
o External user-agents may improve completion rate as the end-user
may already have an active session with the authorization server
removing the need to re-authenticate, and provide a familiar user-
agent user experience. The end-user may also rely on extensions
or add-ons to assist with authentication (e.g. password managers
or 2-factor device reader).
o Embedded user-agents often offer a better end-user flow, as they
remove the need to switch context and open new windows but also
may provide less familiar features than the external user-agent.
o Embedded user-agents pose a security challenge because end-users
are authenticating in an unidentified window without access to the
visual protections offered by many user-agents. Embedded user-
agents educate end-user to trust unidentified requests for
authentication (making phishing attacks easier to execute).
10. Security Considerations
As a flexible and extensible framework, OAuth's security
considerations depend on many factors. The following sections
provide implementers with security guidelines focused on three common
client types:
Web Application
A web application is a client running on a web server. End-users
access the client via an HTML user interface rendered in a user-
agent on the end-user's device. The client credentials as well as
any access token issued to the client are stored on the web server
and are not exposed to or accessible by the end-user.
User-Agent-based Application
A user-agent-based application is a client in which the client
code is downloaded from a web server and executes within a user-
agent on the end-user's device. The OAuth protocol data and
credentials are accessible to the end-user. Since such
applications directly reside within the user-agent, they can make
seamless use of the user-agent capabilities in the end-user
authorization process.
Native Application
A native application is a client which is installed and executes
on the end-user's device. The OAuth protocol data and credentials
are accessible to the end-user. It is assumed that such an
application can protect dynamically issued credentials, such as
refresh tokens, from eavesdropping by other applications residing
on the same device.
A comprehensive OAuth security model and analysis, as well as
background for the protocol design is provided in
[I-D.lodderstedt-oauth-security].
10.1. Client Authentication
The authorization server issues client credentials to web
applications for the purpose of authenticating them. The
authorization server is encouraged to consider using stronger client
authentication means than a client password. Application developers
MUST ensure confidentiality of client passwords and other
credentials.
The authorization server MUST NOT issue client passwords or other
credentials to native or user-agent-based applications for the
purpose of client authentication. The authorization server MAY issue
a client password or other credentials for a specific installation of
a native application on a specific device.
10.2. Client Impersonation
Given the inability of some clients to keep their client credentials
confidential, a malicious client can impersonate another client and
obtain access to protected resources. The authorization server MUST
authenticate the client whenever possible. If the authorization
server cannot authenticate the a client due to the client's
limitations, the authorization server should utilize other means to
protect resource owners from such malicious clients, including but
not limited to engaging the end-user to assist in identifying the
client and its source.
The authorization server SHOULD enforce explicit end-user
authentication, or prompt the end-user to authorize access again,
providing the end-user with information about the client, scope, and
duration of the authorization. It is up to the end-user to review
the information in the context of the current client, and authorize
the request.
The authorization server SHOULD NOT automatically, without active
end-user interaction, process repeated authorization requests without
authenticating the client or relying on other measures to ensure the
repeated request comes from a valid client and not an impersonator.
The authorization server SHOULD require the client to pre-register
its redirection URI and validate the value of the "redirect_uri"
against the pre-registered value. The client MUST NOT serve an open
redirector resource which can be used by an attacker to construct an
URI that will pass the authorization server's redirection URI
matching rules, and will redirect the end-user's user-agent to the
attacker's server.
The authorization server SHOULD issue access tokens with limited
scope and duration to clients incapable of authenticating.
10.3. Access Token Credentials
Access token credentials MUST be kept confidential in transit and
storage, and shared only among the authorization server, the resource
servers the credentials are valid for, and the client to whom the
credentials were issued.
When using the implicit grant type, the access token credentials are
transmitted in the URI fragment, which can expose the credentials to
unauthorized parties.
The authorization server MUST ensure that access token credentials
cannot be generated, modified, or guessed to produce valid access
token credentials.
The client SHOULD request access token credentials with the minimal
scope and duration necessary. The authorization server SHOULD take
the client identity into account when choosing to honor the requested
scope, and MAY issue credentials with a lesser scope than requested.
10.4. Refresh Tokens
Authorization servers MAY issue refresh tokens to web and native
applications.
Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain
the link between a refresh token and the client to whom it was
issued.
The authorization server MUST verify the link between the refresh
token and client identity whenever the client's identity can be
authenticated. When client authentication is not possible, the
authorization server SHOULD deploy other means to detect refresh
token abuse.
The authorization server MUST ensure that refresh tokens cannot be
generated, modified, or guessed to produce valid refresh tokens.
10.5. Request Confidentiality
Access token credentials, refresh tokens, resource owner passwords,
and client secrets MUST NOT be transmitted in the clear.
Authorization codes SHOULD NOT be transmitted in the clear.
10.6. Endpoints Authenticity
In order to prevent man-in-the-middle and phishing attacks, the
authorization server MUST implement and require TLS with server-side
authentication in all exchanges. The client MUST verify the
authorization server's TLS certificate, as well as the respective
certificate chain.
10.7. Credentials Guessing Attacks
The authorization server MUST prevent attackers from guessing access
tokens, authorization codes, refresh tokens, resource owner
passwords, and client secrets.
When generating tokens and other secrets not intended for direct
human utilization, the authorization server MUST use a reasonable
level of entropy in order to mitigate the risk of guessing attacks.
When creating secrets intended for human usage, the authorization
server MUST utilize other means to protect those secrets.
10.8. Phishing Attacks
Native applications SHOULD use external browsers instead of embedding
browsers within the application when requesting end-user
authorization. External browsers offer a familiar user experience
and a trusted environment in which end-users can confirm the
authenticity of the authorization server.
To reduce the risk of phishing attacks, the authorization servers
MUST utilize TLS to allow user-agents to validate the authorization
server's identity. Service providers should educate their end-users
about the risks of phishing attacks and how they can verify the
authorization server's identity.
10.9. Authorization Codes
The transmission of authorization codes SHOULD be made over a secure
channel, and the client SHOULD implement TLS for use with its
redirection URI if the URI identifies a network resource.
Authorization codes MUST be kept confidential. Since authorization
codes are transmitted via user-agent redirections, they could
potentially be disclosed through user-agent history and HTTP referrer
headers.
Authorization codes operate as plaintext bearer credentials, used to
verify that the end-user who granted authorization at the
authorization server, is the same end-user returning to the client to
complete the process. Therefore, if the client relies on the
authorization code for its own end-user authentication, the client
redirection endpoint MUST require TLS.
Authorization codes SHOULD be short lived and MUST be single use. If
the authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server
SHOULD revoke all access tokens already granted based on the
compromised authorization code.
If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was
issued to the same client.
10.10. Session Fixation
Session fixation attacks leverage the authorization code grant type,
by tricking an end-user to authorize access to a legitimate client,
but to a client account under the control of the attacker. The only
difference between a valid flow and the attack flow is in how the
victim reached the authorization server to grant access. Once at the
authorization server, the victim is prompted with a normal, valid
request on behalf of a legitimate and familiar client. The attacker
then uses the victim's authorization to gain access to the
information authorized by the victim.
In order to prevent such an attack, authorization servers MUST ensure
that the redirection URI used to obtain the authorization code, is
the same as the redirection URI provided when exchanging the
authorization code for an access token. The authorization server
SHOULD require the client to pre-register their redirection URI and
if provided, MUST validate the redirection URI received in the
authorization request against the pre-registered value.
10.11. Redirection URI Validation
[[ Add specific recommendations about redirection validation and
matching ]]
10.12. Resource Owner Password Credentials
The resource owner password credentials grant type is often used for
legacy or migration reasons. It reduces the overall risk of storing
username and password in the client, but does not eliminate the need
to expose highly privileged credentials to the client.
This grant type carries a higher risk than the other grant types
because it maintains the password anti-pattern OAuth seeks to avoid.
The client could abuse the password or the password could
unintentionally be disclosed to an attacker (e.g. via log files or
other records kept by the client).
Additionally, because the resource owner does not have control over
the authorization process (the resource owner involvement ends when
it hands over its credentials to the client), the client can obtain
access tokens with a broader scope and longer duration than desired
by the resource owner. The authorization server SHOULD restrict the
scope and duration of access tokens issued via this grant type.
The authorization server and client SHOULD minimize use of this grant
type and utilize other grant types whenever possible.
10.13. XSRF/CSRF Prevention
[[ Add text with reference to the 'state' parameter ]]
11. IANA Considerations
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 on the advice of one or more
Designated Experts (appointed by the IESG or their delegate), with a Designated Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]). However, Specification Required (using terminology from [RFC5226]). However,
to allow for the allocation of values prior to publication, the to allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
that such a specification will be published. that such a specification will be published.
skipping to change at page 39, line 45 skipping to change at page 47, line 30
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
10.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 10.2. Section 11.2.
HTTP Authentication Scheme(s): HTTP Authentication Scheme(s):
The HTTP authentication scheme name(s), if any, used to The HTTP authentication scheme name(s), if any, used to
authenticate protected resources requests using access token of authenticate protected resources requests using access token of
this type. this type.
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):
Reference to document that specifies the parameter, preferably Reference to document that specifies the parameter, preferably
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.
10.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 on the advice
of one or more Designated Experts (appointed by the IESG or their of one or more Designated Experts (appointed by the IESG or their
delegate), with a Specification Required (using terminology from delegate), with a Specification Required (using terminology from
[RFC5226]). However, to allow for the allocation of values prior to [RFC5226]). However, to allow for the allocation of values prior to
publication, the Designated Expert(s) may approve registration once publication, the Designated Expert(s) may approve registration once
skipping to change at page 41, line 11 skipping to change at page 48, line 41
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
10.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:
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):
Reference to document that specifies the parameter, preferably Reference to document that specifies the parameter, preferably
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.
10.2.2. Initial Registry Contents 11.2.2. Initial Registry Contents
The OAuth Parameters Registry's initial contents are: The OAuth Parameters Registry's initial contents are:
o Parameter name: client_id o Parameter name: client_id
o Parameter usage location: authorization request, token request o Parameter usage location: authorization request, token request
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Parameter name: client_secret o Parameter name: client_secret
o Parameter usage location: token request o Parameter usage location: token request
skipping to change at page 43, line 23 skipping to change at page 51, line 8
o Parameter name: password o Parameter name: password
o Parameter usage location: token request o Parameter usage location: token request
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Parameter name: refresh_token o Parameter name: refresh_token
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 ]]
10.3. The OAuth Extensions Error Registry 11.3. The OAuth Extensions Error Registry
[[ Pending Consensus ]]
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 on the advice of one or more Designated
Experts (appointed by the IESG or their delegate), with a Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]). However, Specification Required (using terminology from [RFC5226]). However,
to allow for the allocation of values prior to publication, the to allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
skipping to change at page 44, line 13 skipping to change at page 51, line 44
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
10.3.1. Registration Template 11.3.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).
Related protocol extension: Related protocol extension:
The name of the extension grant type, access token type, or The name of the extension grant type, access token type, or
extension parameter, the error code is used in conjunction with. extension parameter, the error code is used in conjunction with.
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):
Reference to document that specifies the error code, preferably Reference to document that specifies the error code, preferably
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. Acknowledgements 12. Acknowledgements
This specification is the work of the OAuth Working Group which
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
which shaped and formed the final specification:
Michael Adams, Andrew Arnott, Dirk Balfanz, Blaine Cook, Brian
Campbell, Leah Culver, Bill de hOra, Brian Eaton, Brian Ellin, Igor
Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland,
Brent Goldman, Kristoffer Gronowski, Justin Hart, Craig Heath, Phil
Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen
Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Paul
Madsen, Alastair Mair, Eve Maler, James Manger, Laurence Miao, Chuck
Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre,
Marius Scurtescu, Naitik Shah, Luke Shepard, Justin Smith, Jeremy
Suriel, Christian Stuebner, Paul Tarjan, Allen Tom, Franklin Tse,
Nick Walker, Skylar Woodward.
The initial OAuth 2.0 protocol specification was edited by David The initial OAuth 2.0 protocol specification was edited by David
Recordon, based on two previous publications: the OAuth 1.0 community Recordon, based on two previous publications: the OAuth 1.0 community
specification [RFC5849], and OAuth WRAP (OAuth Web Resource specification [RFC5849], and OAuth WRAP (OAuth Web Resource
Authorization Profiles) [I-D.draft-hardt-oauth-01]. Authorization Profiles) [I-D.draft-hardt-oauth-01]. The Security
Considerations section was drafted by Torsten Lodderstedt, Mark
McGloin, Phil Hunt, and Anthony Nadalin.
The OAuth 1.0 community specification was edited by Eran Hammer-Lahav The OAuth 1.0 community specification was edited by Eran Hammer-Lahav
and authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. and authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M.
Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton,
Kellan Elliott-McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie, Kellan Elliott-McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie,
Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran
Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy
Smith. Smith.
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
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
which shaped and formed the final specification:
Michael Adams, Andrew Arnott, Dirk Balfanz, Scott Cantor, Blaine
Cook, Brian Campbell, Leah Culver, Bill de hOra, Brian Eaton, Brian
Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan Gilbert,
Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, Craig
Heath, Phil Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi
Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-
Lan Lu, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark
McGloin, Laurence Miao, Chuck Mortimore, Justin Richer, Peter Saint-
Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke
Shepard, Vlad Skvortsov, Justin Smith, Jeremy Suriel, Christian
Stuebner, Paul Tarjan, Allen Tom, Franklin Tse, Nick Walker, Skylar
Woodward.
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. It is these individuals
without whom this work would not have existed, or reached its without whom this work would not have existed, or reached its
successful conclusion. successful conclusion.
David Recordon for continuously being one of OAuth's most valuable David Recordon for continuously being one of OAuth's most valuable
skipping to change at page 46, line 5 skipping to change at page 53, line 40
Andre, and Hannes Tschofenig for their work as working group chairs. Andre, and Hannes Tschofenig for their work as working group chairs.
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.
Special thanks goes to Mike Curtis and Yahoo! for their unconditional Special thanks goes to Mike Curtis and Yahoo! for their unconditional
support of this work for over three years. support of this work for over three years.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 46, line 39 skipping to change at page 54, line 28
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
12.2. Informative References 13.2. Informative References
[I-D.draft-hardt-oauth-01] [I-D.draft-hardt-oauth-01]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
Web Resource Authorization Profiles", January 2010. Web Resource Authorization Profiles", January 2010.
[I-D.hammer-oauth-v2-mac-token]
Hammer-Lahav, E., "HTTP Authentication: MAC
Authentication", draft-hammer-oauth-v2-mac-token-02 (work
in progress), January 2011.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Grant Type Profile for OAuth 2.0", Grant Type Profile for OAuth 2.0",
draft-ietf-oauth-saml2-bearer-03 (work in progress), draft-ietf-oauth-saml2-bearer-03 (work in progress),
February 2011. February 2011.
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-02 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04
(work in progress), January 2011. (work in progress), March 2011.
[I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP
Authentication: MAC Access Authentication",
draft-ietf-oauth-v2-http-mac-00 (work in progress),
May 2011.
[I-D.lodderstedt-oauth-security]
Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations",
draft-lodderstedt-oauth-security-01 (work in progress),
March 2011.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
 End of changes. 86 change blocks. 
199 lines changed or deleted 554 lines changed or added

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