draft-ietf-oauth-v2-26.txt   draft-ietf-oauth-v2-27.txt 
Network Working Group E. Hammer, Ed. OAuth Working Group E. Hammer, Ed.
Internet-Draft Internet-Draft
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) D. Recordon
Intended status: Standards Track Facebook Intended status: Standards Track Facebook
Expires: November 2, 2012 D. Hardt Expires: December 10, 2012 D. Hardt
Microsoft Microsoft
May 1, 2012 June 8, 2012
The OAuth 2.0 Authorization Framework The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-26 draft-ietf-oauth-v2-27
Abstract Abstract
The OAuth 2.0 authorization framework enables a third-party The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849. in RFC 5849.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 2, 2012. This Internet-Draft will expire on December 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 22 3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 22
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 23 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 23
4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 23 4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 23
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24
4.1.2. Authorization Response . . . . . . . . . . . . . . . . 25 4.1.2. Authorization Response . . . . . . . . . . . . . . . . 25
4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 27 4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 27
4.1.4. Access Token Response . . . . . . . . . . . . . . . . 28 4.1.4. Access Token Response . . . . . . . . . . . . . . . . 28
4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 29 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 29
4.2.1. Authorization Request . . . . . . . . . . . . . . . . 31 4.2.1. Authorization Request . . . . . . . . . . . . . . . . 31
4.2.2. Access Token Response . . . . . . . . . . . . . . . . 32 4.2.2. Access Token Response . . . . . . . . . . . . . . . . 32
4.3. Resource Owner Password Credentials Grant . . . . . . . . 34 4.3. Resource Owner Password Credentials Grant . . . . . . . . 35
4.3.1. Authorization Request and Response . . . . . . . . . . 36 4.3.1. Authorization Request and Response . . . . . . . . . . 36
4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 36 4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 36
4.3.3. Access Token Response . . . . . . . . . . . . . . . . 37 4.3.3. Access Token Response . . . . . . . . . . . . . . . . 37
4.4. Client Credentials Grant . . . . . . . . . . . . . . . . 37 4.4. Client Credentials Grant . . . . . . . . . . . . . . . . 37
4.4.1. Authorization Request and Response . . . . . . . . . . 38 4.4.1. Authorization Request and Response . . . . . . . . . . 38
4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 38 4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 38
4.4.3. Access Token Response . . . . . . . . . . . . . . . . 39 4.4.3. Access Token Response . . . . . . . . . . . . . . . . 39
4.5. Extension Grants . . . . . . . . . . . . . . . . . . . . 39 4.5. Extension Grants . . . . . . . . . . . . . . . . . . . . 39
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 40 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 40
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 40 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 40
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 41 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 41
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 43 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 43
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 44 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 44
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 44 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 45
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Error Response . . . . . . . . . . . . . . . . . . . . . 46
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 45 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 46 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 46
8.3. Defining New Authorization Grant Types . . . . . . . . . 46 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 47
8.4. Defining New Authorization Endpoint Response Types . . . 46 8.3. Defining New Authorization Grant Types . . . . . . . . . 47
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 47 8.4. Defining New Authorization Endpoint Response Types . . . 47
9. Native Applications . . . . . . . . . . . . . . . . . . . . . 47 8.5. Defining Additional Error Codes . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 48
10.1. Client Authentication . . . . . . . . . . . . . . . . . . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 49 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 50
10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 50 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 50
10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 51 10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 51
10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 51 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 52
10.6. Authorization Code Redirection URI Manipulation . . . . . 52 10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 52
10.7. Resource Owner Password Credentials . . . . . . . . . . . 53 10.6. Authorization Code Redirection URI Manipulation . . . . . 53
10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 53 10.7. Resource Owner Password Credentials . . . . . . . . . . . 54
10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 53 10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 54
10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 53 10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 54
10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 54 10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 54
10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 54 10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 55
10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 55 10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 55
10.14. Code Injection and Input Validation . . . . . . . . . . . 56 10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 56
10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 56 10.14. Code Injection and Input Validation . . . . . . . . . . . 57
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 57
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 56 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
11.1.1. Registration Template . . . . . . . . . . . . . . . . 57 11.1. The OAuth Access Token Type Registry . . . . . . . . . . 57
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 57 11.1.1. Registration Template . . . . . . . . . . . . . . . . 58
11.2.1. Registration Template . . . . . . . . . . . . . . . . 58 11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 58
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 58 11.2.1. Registration Template . . . . . . . . . . . . . . . . 59
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 59
11.3. The OAuth Authorization Endpoint Response Type 11.3. The OAuth Authorization Endpoint Response Type
Registry . . . . . . . . . . . . . . . . . . . . . . . . 60 Registry . . . . . . . . . . . . . . . . . . . . . . . . 61
11.3.1. Registration Template . . . . . . . . . . . . . . . . 61 11.3.1. Registration Template . . . . . . . . . . . . . . . . 62
11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 61 11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 62
11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 61 11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 62
11.4.1. Registration Template . . . . . . . . . . . . . . . . 62 11.4.1. Registration Template . . . . . . . . . . . . . . . . 63
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 63 12.2. Informative References . . . . . . . . . . . . . . . . . 65
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 65
13.1. Normative References . . . . . . . . . . . . . . . . . . 64 A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . 65 A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 66
A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 66
A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 66
A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 67
A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 67
A.8. "error_description" Syntax . . . . . . . . . . . . . . . 67
A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 67
A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 67
A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 67
A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 68
A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 68
A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 68
A.15. "username" Syntax . . . . . . . . . . . . . . . . . . . . 68
A.16. "password" Syntax . . . . . . . . . . . . . . . . . . . . 68
A.17. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 68
A.18. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 69
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 69
Appendix C. Editor's Notes . . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
requests an access restricted resource (protected resource) on the requests an access restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with restricted resources, the resource owner shares its credentials with
the third-party. This creates several problems and limitations: the third-party. This creates several problems and limitations:
skipping to change at page 13, line 12 skipping to change at page 13, line 12
work will define prescriptive profiles and extensions necessary to work will define prescriptive profiles and extensions necessary to
achieve full web-scale interoperability. achieve full web-scale interoperability.
1.9. Notational Conventions 1.9. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in [RFC2119]. specification are to be interpreted as described in [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234]. Additionally, the rule URI-Reference is
included from Uniform Resource Identifier (URI) [RFC3986].
Certain security-related terms are to be understood in the sense Certain security-related terms are to be understood in the sense
defined in [RFC4949]. These terms include, but are not limited to, defined in [RFC4949]. These terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate", "attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity", "sign", "confidentiality", "credential", "encryption", "identity", "sign",
"signature", "trust", "validate", and "verify". "signature", "trust", "validate", and "verify".
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
skipping to change at page 13, line 42 skipping to change at page 13, line 43
client and the authorization server. When supported by the client and the authorization server. When supported by the
authorization server, registration can rely on other means for authorization server, registration can rely on other means for
establishing trust and obtaining the required client properties (e.g. establishing trust and obtaining the required client properties (e.g.
redirection URI, client type). For example, registration can be redirection URI, client type). For example, registration can be
accomplished using a self-issued or third-party-issued assertion, or accomplished using a self-issued or third-party-issued assertion, or
by the authorization server performing client discovery using a by the authorization server performing client discovery using a
trusted channel. trusted channel.
When registering a client, the client developer SHALL: When registering a client, the client developer SHALL:
o specifies the client type as described in Section 2.1, o specify the client type as described in Section 2.1,
o provides its client redirection URIs as described in o provide its client redirection URIs as described in Section 3.1.2,
Section 3.1.2, and and
o includes any other information required by the authorization o include any other information required by the authorization server
server (e.g. application name, website, description, logo image, (e.g. application name, website, description, logo image, the
the acceptance of legal terms). acceptance of legal terms).
2.1. Client Types 2.1. Client Types
OAuth defines two client types, based on their ability to OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e. ability to authenticate securely with the authorization server (i.e. ability to
maintain the confidentiality of their client credentials): maintain the confidentiality of their client credentials):
confidential confidential
Clients capable of maintaining the confidentiality of their Clients capable of maintaining the confidentiality of their
credentials (e.g. client implemented on a secure server with credentials (e.g. client implemented on a secure server with
skipping to change at page 15, line 23 skipping to change at page 15, line 23
credentials are protected from hostile servers with which the credentials are protected from hostile servers with which the
application may interact with. On some platforms these application may interact with. On some platforms these
credentials might be protected from other applications residing on credentials might be protected from other applications residing on
the same device. the same device.
2.2. Client Identifier 2.2. Client Identifier
The authorization server issues the registered client a client The authorization server issues the registered client a client
identifier - a unique string representing the registration identifier - a unique string representing the registration
information provided by the client. The client identifier is not a information provided by the client. The client identifier is not a
secret, it is exposed to the resource owner, and MUST NOT be used secret; it is exposed to the resource owner, and MUST NOT be used
alone for client authentication. The client identifier is unique to alone for client authentication. The client identifier is unique to
the authorization server. the authorization server.
The client identifier string size is left undefined by this The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size identifier size. The authorization server SHOULD document the size
of any identifier it issues. of any identifier it issues.
2.3. Client Authentication 2.3. Client Authentication
skipping to change at page 26, line 39 skipping to change at page 26, line 39
error, and MUST NOT automatically redirect the user-agent to the error, and MUST NOT automatically redirect the user-agent to the
invalid redirection URI. invalid redirection URI.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
invalid parameter value, includes a parameter more than invalid parameter value, includes a parameter more than
once, or is otherwise malformed. once, or is otherwise malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an authorization The client is not authorized to request an authorization
code using this method. code using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
skipping to change at page 27, line 20 skipping to change at page 27, line 20
authorization code using this method. authorization code using this method.
invalid_scope invalid_scope
The requested scope is invalid, unknown, or malformed. The requested scope is invalid, unknown, or malformed.
server_error server_error
The authorization server encountered an unexpected The authorization server encountered an unexpected
condition which prevented it from fulfilling the request. condition which prevented it from fulfilling the request.
temporarily_unavailable temporarily_unavailable
The authorization server is currently unable to handle The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance the request due to a temporary overloading or maintenance
of the server. of the server.
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
error_description error_description
OPTIONAL. A human-readable UTF-8 encoded text providing OPTIONAL. A human-readable ASCII [USASCII] text providing
additional information, used to assist the client developer in additional information, used to assist the client developer in
understanding the error that occurred. understanding the error that occurred.
Values for the "error_description" parameter MUST NOT include
characters outside the set %x20-21 / %x23-5B / %x5D-7E.
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 client information about the error, used to provide the client
developer with additional information about the error. developer with additional information about the error.
Values for the "error_uri" parameter MUST conform to the URI-
Reference syntax, and thus MUST NOT include characters outside
the set %x21 / %x23-5B / %x5D-7E.
state state
REQUIRED if a "state" parameter was present in the client REQUIRED if a "state" parameter was present in the client
authorization request. The exact value received from the authorization request. The exact value received from the
client. 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&state=xyz Location: https://client.example.com/cb?error=access_denied&state=xyz
skipping to change at page 33, line 47 skipping to change at page 33, line 47
error, and MUST NOT automatically redirect the user-agent to the error, and MUST NOT automatically redirect the user-agent to the
invalid redirection URI. invalid redirection URI.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the fragment component of the redirection URI using the parameters to the fragment component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
invalid parameter value, includes a parameter more than invalid parameter value, includes a parameter more than
once, or is otherwise malformed. once, or is otherwise malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an access token The client is not authorized to request an access token
using this method. using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
skipping to change at page 34, line 27 skipping to change at page 34, line 27
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.
server_error server_error
The authorization server encountered an unexpected The authorization server encountered an unexpected
condition which prevented it from fulfilling the request. condition which prevented it from fulfilling the request.
temporarily_unavailable temporarily_unavailable
The authorization server is currently unable to handle The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance the request due to a temporary overloading or maintenance
of the server. of the server.
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
error_description error_description
OPTIONAL. A human-readable UTF-8 encoded text providing OPTIONAL. A human-readable ASCII [USASCII] text providing
additional information, used to assist the client developer in additional information, used to assist the client developer in
understanding the error that occurred. understanding the error that occurred.
Values for the "error_description" parameter MUST NOT include
characters outside the set %x20-21 / %x23-5B / %x5D-7E.
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 client information about the error, used to provide the client
developer with additional information about the error. developer with additional information about the error.
Values for the "error_uri" parameter MUST conform to the URI-
Reference syntax, and thus MUST NOT include characters outside
the set %x21 / %x23-5B / %x5D-7E.
state state
REQUIRED if a "state" parameter was present in the client REQUIRED if a "state" parameter was present in the client
authorization request. The exact value received from the authorization request. The exact value received from the
client. 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&state=xyz Location: https://client.example.com/cb#error=access_denied&state=xyz
skipping to change at page 41, line 42 skipping to change at page 41, line 42
assumptions about value sizes. The authorization server SHOULD assumptions about value sizes. The authorization server SHOULD
document the size of any value it issues. document the size of any value it issues.
5.2. Error Response 5.2. Error Response
The authorization server responds with an HTTP 400 (Bad Request) The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise) and includes the following status code (unless specified otherwise) and includes the following
parameters with the response: parameters with the response:
error error
REQUIRED. A single error code from the following: REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
unsupported parameter value (other than grant type), unsupported parameter value (other than grant type),
repeats a parameter, includes multiple credentials, repeats a parameter, includes multiple credentials,
utilizes more than one mechanism for authenticating the utilizes more than one mechanism for authenticating the
client, or is otherwise malformed. client, or is otherwise malformed.
invalid_client invalid_client
Client authentication failed (e.g. unknown client, no Client authentication failed (e.g. unknown client, no
client authentication included, or unsupported client authentication included, or unsupported
skipping to change at page 42, line 31 skipping to change at page 42, line 31
another client. 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.
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.
error_description error_description
OPTIONAL. A human-readable UTF-8 encoded text providing OPTIONAL. A human-readable ASCII [USASCII] text providing
additional information, used to assist the client developer in additional information, used to assist the client developer in
understanding the error that occurred. understanding the error that occurred.
Values for the "error_description" parameter MUST NOT include
characters outside the set %x20-21 / %x23-5B / %x5D-7E.
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 client information about the error, used to provide the client
developer with additional information about the error. developer with additional information about the error.
Values for the "error_uri" parameter MUST conform to the URI-
Reference syntax, and thus MUST NOT include characters outside
the set %x21 / %x23-5B / %x5D-7E.
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
as JSON numbers. The order of parameters does not matter and can as JSON numbers. The order of parameters does not matter and can
vary. vary.
For example: For example:
skipping to change at page 44, line 40 skipping to change at page 45, line 5
The client accesses protected resources by presenting the access The client accesses protected resources by presenting the access
token to the resource server. The resource server MUST validate the token to the resource server. The resource server MUST validate the
access token and ensure it has not expired and that its scope covers access token and ensure it has not expired and that its scope covers
the requested resource. The methods used by the resource server to the requested resource. The methods used by the resource server to
validate the access token (as well as any error responses) are beyond validate the access token (as well as any error responses) are beyond
the scope of this specification, but generally involve an interaction the scope of this specification, but generally involve an interaction
or coordination between the resource server and the authorization or coordination between the resource server and the authorization
server. server.
The method in which the client utilized the access token to The method in which the client utilizes 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). The client resource request (along with type-specific attributes). The client
MUST NOT use an access token if it does not understand the token MUST NOT use an access token if it does not understand the token
type. 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 7Fjfp0ZBr1KtDRbnfVdmIw Authorization: Bearer mF_9.B5f-4.1JqM
while the "mac" token type defined in [I-D.ietf-oauth-v2-http-mac] is while the "mac" token type defined in [I-D.ietf-oauth-v2-http-mac] is
utilized by issuing a MAC key together with the access token which is utilized by issuing a MAC key together with the access token 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 id="h480djs93hd8", Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s", nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
The above examples are provided for illustration purposes only. The above examples are provided for illustration purposes only.
Developers are advised to consult the [I-D.ietf-oauth-v2-bearer] and Developers are advised to consult the [I-D.ietf-oauth-v2-bearer] and
[I-D.ietf-oauth-v2-http-mac] specifications before use. [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.
7.2. Error Response
If a resource access request fails, the resource server SHOULD inform
the client of the error. While the specific error responses possible
and methods for transmitting those errors when using any particular
access token type are beyond the scope of this specification, any
"error" code values defined for use with OAuth resource access
methods MUST be registered (following the procedures in
Section 11.4).
Specifically, when the OAuth resource access method uses an "error"
result parameter to return an error code value that indicates the
resource access error encountered, then these error code values MUST
be registered. Values for these "error" codes MUST NOT include
characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an
"error" code value is registered for use by an OAuth resource access
method, should that same code already be registered for use by
another OAuth resource access method or at a different OAuth error
usage location, then the meaning of that error code value in in the
new registration MUST be consistent with the its meaning in prior
registrations.
The OAuth resource access error registration requirement applies only
to "error" code values and not to other means of returning error
indications, including HTTP status codes, or other error-related
result parameters, such as "error_description", "error_uri", or other
kinds of error status return methods that may be employed by the
resource access method. There is no requirement that OAuth resource
access methods employ an "error" parameter.
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 11.1), or by using a unique absolute URI as its name. Section 11.1), or by using 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]). The token type authentication scheme name (as defined by [RFC2617]). The token type
"example" is reserved for use in examples. "example" is reserved for use in examples.
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 11.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).
skipping to change at page 47, line 26 skipping to change at page 48, line 22
"token code" response type. Once registered, the same combination "token code" response type. Once registered, the same combination
cannot be registered as "code token", but both values can be used to cannot be registered as "code token", but both values can be used to
denote the same response type. denote the same response type.
8.5. Defining Additional Error Codes 8.5. Defining Additional Error Codes
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), the token error response (Section 5.2), or the
error codes MAY be defined. resource access error response (Section 7.2), such 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 11.4) if the extension they are used in conjunction with is a Section 11.4) if the extension they are used in conjunction with is a
registered access token type, a registered endpoint parameter, or an registered access token type, a registered endpoint parameter, or an
extension grant type. Error codes used with unregistered extensions extension grant type. Error codes used with unregistered extensions
MAY be registered. MAY be registered.
Error codes MUST conform to the error-code ABNF, and SHOULD be Error codes MUST conform to the error ABNF, and SHOULD be prefixed by
prefixed by an identifying name when possible. For example, an error an identifying name when possible. For example, an error identifying
identifying an invalid value set to the extension parameter "example" an invalid value set to the extension parameter "example" SHOULD be
SHOULD be named "example_invalid". named "example_invalid".
error-code = ALPHA *error-char error = 1*error-char
error-char = "-" / "." / "_" / DIGIT / ALPHA error-char = %x20-21 / %x23-5B / %x5D-7E
9. Native Applications 9. Native Applications
Native applications are clients installed and executed on the device Native applications are clients installed and executed on the device
used by the resource owner (i.e. desktop application, native mobile used by the resource owner (i.e. desktop application, native mobile
application). Native applications require special consideration application). Native applications require special consideration
related to security, platform capabilities, and overall end-user related to security, platform capabilities, and overall end-user
experience. experience.
The authorization endpoint requires interaction between the client The authorization endpoint requires interaction between the client
skipping to change at page 50, line 50 skipping to change at page 51, line 50
generated, modified, or guessed to produce valid access tokens by generated, modified, or guessed to produce valid access tokens by
unauthorized parties. unauthorized parties.
The client SHOULD request access tokens with the minimal scope The client SHOULD request access tokens with the minimal scope
necessary. The authorization server SHOULD take the client identity necessary. The authorization server SHOULD take the client identity
into account when choosing how to honor the requested scope, and MAY into account when choosing how to honor the requested scope, and MAY
issue an access token with a less rights than requested. issue an access token with a less rights than requested.
This specification does not provide any methods for the resource This specification does not provide any methods for the resource
server to ensure that an access token presented to it by a given server to ensure that an access token presented to it by a given
client, was issued to the that client by the authorization server. client was issued to that client by the authorization server.
10.4. Refresh Tokens 10.4. Refresh Tokens
Authorization servers MAY issue refresh tokens to web application Authorization servers MAY issue refresh tokens to web application
clients and native application clients. clients and native application clients.
Refresh tokens MUST be kept confidential in transit and storage, and Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was the binding between a refresh token and the client to whom it was
skipping to change at page 55, line 48 skipping to change at page 56, line 48
button). This allows an attacker to trick a resource owner into button). This allows an attacker to trick a resource owner into
granting its client access without their knowledge. granting its client access without their knowledge.
To prevent this form of attack, native applications SHOULD use To prevent this form of attack, native applications SHOULD use
external browsers instead of embedding browsers within the external browsers instead of embedding browsers within the
application when requesting end-user authorization. For most newer application when requesting end-user authorization. For most newer
browsers, avoidance of iframes can be enforced by the authorization browsers, avoidance of iframes can be enforced by the authorization
server using the (non-standard) "x-frame-options" header. This server using the (non-standard) "x-frame-options" header. This
header can have two values, "deny" and "sameorigin", which will block header can have two values, "deny" and "sameorigin", which will block
any framing, or framing by sites with a different origin, any framing, or framing by sites with a different origin,
respectively. For older browsers, javascript framebusting techniques respectively. For older browsers, JavaScript framebusting techniques
can be used but may not be effective in all browsers. can be used but may not be effective in all browsers.
10.14. Code Injection and Input Validation 10.14. Code Injection and Input Validation
A code injection attack occurs when an input or otherwise external A code injection attack occurs when an input or otherwise external
variable is used by an application unsanitized and causes variable is used by an application unsanitized and causes
modification to the application logic. This may allow an attacker to modification to the application logic. This may allow an attacker to
gain access to the application device or its data, cause denial of gain access to the application device or its data, cause denial of
service, or a wide range of malicious side-effects. service, or a wide range of malicious side-effects.
skipping to change at page 56, line 42 skipping to change at page 57, line 42
code or access token to an endpoint under the control of the code or access token to an endpoint under the control of the
attacker. attacker.
11. IANA Considerations 11. IANA Considerations
11.1. The OAuth Access Token Type Registry 11.1. The OAuth Access Token Type Registry
This specification establishes the OAuth access token type registry. This specification establishes the OAuth access token type registry.
Access token types are registered with a Specification Required Access token types are registered with a Specification Required
([RFC5226]) after a two weeks review period on the [TBD]@ietf.org ([RFC5226]) after a two week review period on the [TBD]@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Expert(s) may approve registration once they are the Designated Expert(s) may approve registration once they are
satisfied that such a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for access token type: example"). [[ Note to RFC-EDITOR: The name of for access token type: example"). [[ Note to RFC-EDITOR: The name of
the mailing list should be determined in consultation with the IESG the mailing list should be determined in consultation with the IESG
and IANA. Suggested name: oauth-ext-review. ]] and IANA. Suggested name: oauth-ext-review. ]]
skipping to change at page 57, line 46 skipping to change at page 58, line 46
document. An indication of the relevant sections may also be document. An indication of the relevant sections may also be
included, but is not required. included, but is not required.
11.2. The OAuth Parameters Registry 11.2. The OAuth Parameters Registry
This specification establishes the OAuth parameters registry. This specification establishes the OAuth parameters registry.
Additional parameters for inclusion in the authorization endpoint Additional parameters for inclusion in the authorization endpoint
request, the authorization endpoint response, the token endpoint request, the authorization endpoint response, the token endpoint
request, or the token endpoint response are registered with a request, or the token endpoint response are registered with a
Specification Required ([RFC5226]) after a two weeks review period on Specification Required ([RFC5226]) after a two week review period on
the [TBD]@ietf.org mailing list, on the advice of one or more the [TBD]@ietf.org mailing list, on the advice of one or more
Designated Experts. However, to allow for the allocation of values Designated Experts. However, to allow for the allocation of values
prior to publication, the Designated Expert(s) may approve prior to publication, the Designated Expert(s) may approve
registration once they are satisfied that such a specification will registration once they are satisfied that such a specification will
be published. be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for parameter: example"). [[ Note to RFC-EDITOR: The name of the for parameter: example"). [[ Note to RFC-EDITOR: The name of the
mailing list should be determined in consultation with the IESG and mailing list should be determined in consultation with the IESG and
skipping to change at page 60, line 38 skipping to change at page 61, line 38
o Parameter usage location: token request, token response o Parameter usage location: token request, token response
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
11.3. The OAuth Authorization Endpoint Response Type Registry 11.3. The OAuth Authorization Endpoint Response Type Registry
This specification establishes the OAuth authorization endpoint This specification establishes the OAuth authorization endpoint
response type registry. response type registry.
Additional response type for use with the authorization endpoint are Additional response type for use with the authorization endpoint are
registered with a Specification Required ([RFC5226]) after a two registered with a Specification Required ([RFC5226]) after a two week
weeks review period on the [TBD]@ietf.org mailing list, on the advice review period on the [TBD]@ietf.org mailing list, on the advice of
of one or more Designated Experts. However, to allow for the one or more Designated Experts. However, to allow for the allocation
allocation of values prior to publication, the Designated Expert(s) of values prior to publication, the Designated Expert(s) may approve
may approve registration once they are satisfied that such a registration once they are satisfied that such a specification will
specification will be published. be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for response type: example"). [[ Note to RFC-EDITOR: The name of the for response type: example"). [[ Note to RFC-EDITOR: The name of the
mailing list should be determined in consultation with the IESG and mailing list should be determined in consultation with the IESG and
IANA. Suggested name: oauth-ext-review. ]] IANA. Suggested name: oauth-ext-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
skipping to change at page 61, line 47 skipping to change at page 62, line 47
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
11.4. The OAuth Extensions Error Registry 11.4. The OAuth Extensions Error Registry
This specification establishes the OAuth extensions error registry. This specification establishes the OAuth extensions error registry.
Additional error codes used together with other protocol extensions Additional error codes used together with other protocol extensions
(i.e. extension grant types, access token types, or extension (i.e. extension grant types, access token types, or extension
parameters) are registered with a Specification Required ([RFC5226]) parameters) are registered with a Specification Required ([RFC5226])
after a two weeks review period on the [TBD]@ietf.org mailing list, after a two week review period on the [TBD]@ietf.org mailing list, on
on the advice of one or more Designated Experts. However, to allow the advice of one or more Designated Experts. However, to allow for
for the allocation of values prior to publication, the Designated the allocation of values prior to publication, the Designated
Expert(s) may approve registration once they are satisfied that such Expert(s) may approve registration once they are satisfied that such
a specification will be published. a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for error code: example"). [[ Note to RFC-EDITOR: The name of the for error code: example"). [[ Note to RFC-EDITOR: The name of the
mailing list should be determined in consultation with the IESG and mailing list should be determined in consultation with the IESG and
IANA. Suggested name: oauth-ext-review. ]] IANA. Suggested name: oauth-ext-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
skipping to change at page 62, line 29 skipping to change at page 63, line 29
list. list.
11.4.1. Registration Template 11.4.1. Registration Template
Error name: Error name:
The name requested (e.g., "example"). The name requested (e.g., "example").
Error usage location: Error usage location:
The location(s) where the error can be used. The possible The location(s) where the error can be used. The possible
locations are: authorization code grant error response locations are: authorization code grant error response
(Section 4.1.2.1), implicit grant error response (Section 4.1.2.1), implicit grant error response
(Section 4.2.2.1), or token error response (Section 5.2). (Section 4.2.2.1), token error response (Section 5.2), or resource
access error response (Section 7.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 the document that specifies the error code, Reference to the document that specifies the error code,
preferably including a URI that can be used to retrieve a copy of preferably including a URI that can be used to retrieve a copy of
the document. An indication of the relevant sections may also be the document. An indication of the relevant sections may also be
included, but is not required. included, but is not required.
12. Acknowledgements 12. References
The initial OAuth 2.0 protocol specification was edited by David
Recordon, based on two previous publications: the OAuth 1.0 community
specification [RFC5849], and OAuth WRAP (OAuth Web Resource
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 and
authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M.
Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton,
Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris
Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
The OAuth WRAP specification was edited by Dick Hardt and authored by
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, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
Bell, Brian Campbell, Scott Cantor, Marcos Caceres, Blaine Cook,
Roger Crew, Brian Eaton, Wesley Eddy, Leah Culver, Bill de hOra,
Andre DeMarre, Brian Eaton, Wolter Eldering, Brian Ellin, Igor
Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert,
Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, Dick
Hardt, Craig Heath, Phil Hunt, Michael B. Jones, Terry Jones, John
Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf,
Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair
Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William
Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin
Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu,
Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song,
Niv Steingarten, Christian Stubner, Jeremy Suriel, Paul Tarjan,
Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick
Walker, Shane Weeden, and Skylar Woodward.
This document was produced under the chairmanship of Blaine Cook,
Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area
directors included Lisa Dusseault, Peter Saint-Andre, and Stephen
Farrell.
Appendix A. Editor's Notes
While many people contributed to this specification throughout its
long journey, the editor would like to acknowledge and thank a few
individuals for their outstanding and invaluable efforts leading up
to the publication of this specification.
David Recordon for continuously being one of OAuth's most valuable
assets, bringing pragmatism and urgency to the work, and helping
shape it from its very beginning, as well as being one of the best
collaborators I had the pleasure of working with.
James Manger for his creative ideas and always insightful feedback.
Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer,
Marius Scurtescu, and Luke Shepard for their continued participation
and valuable feedback.
Special thanks goes to Mike Curtis and Yahoo! for their unconditional
support of this work for over three years.
13. References
13.1. Normative References 12.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.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[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.
skipping to change at page 65, line 14 skipping to change at page 64, line 43
[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.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Hors, A., Raggett, D., and I. Jacobs, "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>.
13.2. Informative References 12.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.ietf-httpbis-p7-auth]
Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
progress), March 2012.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Mortimore, C., "SAML 2.0 Bearer Assertion Profiles for Mortimore, C., "SAML 2.0 Bearer Assertion Profiles for
OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work in OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in
progress), August 2011. progress), May 2012.
[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-08 Authorization Protocol: Bearer Tokens",
(work in progress), July 2011. draft-ietf-oauth-v2-bearer-19 (work in progress),
April 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication: MAC Access Authentication", Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
draft-ietf-oauth-v2-http-mac-00 (work in progress), progress), February 2012.
May 2011.
[I-D.ietf-oauth-v2-threatmodel] [I-D.ietf-oauth-v2-threatmodel]
Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0
Threat Model and Security Considerations", Threat Model and Security Considerations",
draft-ietf-oauth-v2-threatmodel-00 (work in progress), draft-ietf-oauth-v2-threatmodel-02 (work in progress),
July 2011. February 2012.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
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.
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
This section provides Augmented Backus-Naur Form (ABNF) syntax
descriptions for the elements defined in this specification using the
notation of [RFC5234]. Elements are presented in the order first
defined.
Some of the definitions that follow use the "URI-reference"
definition from [RFC3986].
Some of the definitions that follow use these common definitions:
VSCHAR = %20-7E
NQCHAR = %x21 / %x23-5B / %x5D-7E
NQSCHAR = %x20-21 / %x23-5B / %x5D-7E
A.1. "client_id" Syntax
The "client_id" element is defined in Section 2.3.1:
client-id = *VSCHAR
(This matches the "userid" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.2. "client_secret" Syntax
The "client_secret" element is defined in Section 2.3.1:
client-secret = *VSCHAR
(This matches the "password" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.3. "response_type" Syntax
The "response_type" element is defined in Section 3.1.1 and
Section 8.4:
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
A.4. "scope" Syntax
The "scope" element is defined in Section 3.3:
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
A.5. "state" Syntax
The "state" element is defined in Section 4.1.1, Section 4.1.2,
Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:
state = 1*VSCHAR
A.6. "redirect_uri" Syntax
The "redirect_uri" element is defined in Section 4.1.1,
Section 4.1.3, and Section 4.2.1:
redirect-uri = URI-reference
A.7. "error" Syntax
The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1,
Section 5.2, Section 7.2, and Section 8.5:
error = 1*NQSCHAR
A.8. "error_description" Syntax
The "error_description" element is defined in Section 4.1.2.1,
Section 4.2.2.1, Section 5.2, and Section 7.2:
error-description = 1*NQSCHAR
A.9. "error_uri" Syntax
The "error_uri" element is defined in Section 4.1.2.1,
Section 4.2.2.1, Section 5.2, and Section 7.2:
error-uri = URI-reference
A.10. "grant_type" Syntax
The "grant_type" element is defined in Section 4.1.3, Section 4.3.2,
Section 4.4.2, Section 6, and Section 4.5:
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
A.11. "code" Syntax
The "code" element is defined in Section 4.1.3:
code = 1*VSCHAR
A.12. "access_token" Syntax
The "access_token" element is defined in Section 4.2.2 and
Section 5.1:
access-token = 1*VSCHAR
A.13. "token_type" Syntax
The "token_type" element is defined in Section 4.2.2, Section 5.1,
and Section 8.1:
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
A.14. "expires_in" Syntax
The "expires_in" element is defined in Section 4.2.2 and Section 5.1:
expires-in = 1*DIGIT
A.15. "username" Syntax
The "username" element is defined in Section 4.3.2:
username = *( %x20-39 / %x3B-7E )
(This allowed character set is VSCHAR excluding ":". This is
compatible with the "userid" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.16. "password" Syntax
The "password" element is defined in Section 4.3.2:
password = *VSCHAR
(This matches the "password" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.17. "refresh_token" Syntax
The "refresh_token" element is defined in Section 5.1 and Section 6:
refresh-token = 1*VSCHAR
A.18. Endpoint Parameter Syntax
The syntax for new endpoint parameters is defined in Section 8.2:
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
Appendix B. Acknowledgements
The initial OAuth 2.0 protocol specification was edited by David
Recordon, based on two previous publications: the OAuth 1.0 community
specification [RFC5849], and OAuth WRAP (OAuth Web Resource
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 ABNF section was
drafted by Michael B. Jones.
The OAuth 1.0 community specification was edited by Eran Hammer and
authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M.
Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton,
Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris
Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler,
Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
The OAuth WRAP specification was edited by Dick Hardt and authored by
Brian Eaton, Yaron Y. 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, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
Bell, John Bradley, Brian Campbell, Scott Cantor, Marcos Caceres,
Blaine Cook, Roger Crew, Brian Eaton, Wesley Eddy, Leah Culver, Bill
de hOra, Andre DeMarre, Brian Eaton, Wolter Eldering, Brian Ellin,
Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan
Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin
Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, Terry
Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus
Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen,
Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao,
William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,
Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius
Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith,
Haibin Song, Niv Steingarten, Christian Stubner, Jeremy Suriel, Paul
Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin
Tse, Nick Walker, Shane Weeden, and Skylar Woodward.
This document was produced under the chairmanship of Blaine Cook,
Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
The area directors included Lisa Dusseault, Peter Saint-Andre, and
Stephen Farrell.
Appendix C. Editor's Notes
While many people contributed to this specification throughout its
long journey, the editor would like to acknowledge and thank a few
individuals for their outstanding and invaluable efforts leading up
to the publication of this specification.
David Recordon for continuously being one of OAuth's most valuable
assets, bringing pragmatism and urgency to the work, and helping
shape it from its very beginning, as well as being one of the best
collaborators I had the pleasure of working with.
James Manger for his creative ideas and always insightful feedback.
Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer,
Marius Scurtescu, and Luke Shepard for their continued participation
and valuable feedback.
Special thanks goes to Mike Curtis and Yahoo! for their unconditional
support of this work for over three years.
Authors' Addresses Authors' Addresses
Eran Hammer (editor) Eran Hammer (editor)
Email: eran@hueniverse.com Email: eran@hueniverse.com
URI: http://hueniverse.com URI: http://hueniverse.com
David Recordon David Recordon
Facebook Facebook
 End of changes. 51 change blocks. 
173 lines changed or deleted 407 lines changed or added

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