draft-ietf-oauth-v2-27.txt   draft-ietf-oauth-v2-28.txt 
OAuth 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: December 10, 2012 D. Hardt Expires: December 21, 2012 D. Hardt
Microsoft Microsoft
June 8, 2012 June 19, 2012
The OAuth 2.0 Authorization Framework The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-27 draft-ietf-oauth-v2-28
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 December 10, 2012. This Internet-Draft will expire on December 21, 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 3, line 25 skipping to change at page 3, line 25
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 44 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 44
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 45 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 45
7.2. Error Response . . . . . . . . . . . . . . . . . . . . . 46 7.2. Error Response . . . . . . . . . . . . . . . . . . . . . 46
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 46 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 46
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 47 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 47
8.3. Defining New Authorization Grant Types . . . . . . . . . 47 8.3. Defining New Authorization Grant Types . . . . . . . . . 47
8.4. Defining New Authorization Endpoint Response Types . . . 47 8.4. Defining New Authorization Endpoint Response Types . . . 47
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 48 8.5. Defining Additional Error Codes . . . . . . . . . . . . . 48
9. Native Applications . . . . . . . . . . . . . . . . . . . . . 48 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Client Authentication . . . . . . . . . . . . . . . . . . 50 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 50
10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 50 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 50
10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 51 10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 51
10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 52 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 51
10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 52 10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 52
10.6. Authorization Code Redirection URI Manipulation . . . . . 53 10.6. Authorization Code Redirection URI Manipulation . . . . . 53
10.7. Resource Owner Password Credentials . . . . . . . . . . . 54 10.7. Resource Owner Password Credentials . . . . . . . . . . . 53
10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 54 10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 54
10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 54 10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 54
10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 54 10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 54
10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 55 10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 54
10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 55 10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 55
10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 56 10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 56
10.14. Code Injection and Input Validation . . . . . . . . . . . 57 10.14. Code Injection and Input Validation . . . . . . . . . . . 56
10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 57 10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 57
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 57 11.1. The OAuth Access Token Type Registry . . . . . . . . . . 57
11.1.1. Registration Template . . . . . . . . . . . . . . . . 58 11.1.1. Registration Template . . . . . . . . . . . . . . . . 58
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 58 11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 58
11.2.1. Registration Template . . . . . . . . . . . . . . . . 59 11.2.1. Registration Template . . . . . . . . . . . . . . . . 59
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 61 Registry . . . . . . . . . . . . . . . . . . . . . . . . 61
11.3.1. Registration Template . . . . . . . . . . . . . . . . 62 11.3.1. Registration Template . . . . . . . . . . . . . . . . 61
11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 62 11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 62
11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 62 11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 62
11.4.1. Registration Template . . . . . . . . . . . . . . . . 63 11.4.1. Registration Template . . . . . . . . . . . . . . . . 63
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
12.1. Normative References . . . . . . . . . . . . . . . . . . 63 12.1. Normative References . . . . . . . . . . . . . . . . . . 63
12.2. Informative References . . . . . . . . . . . . . . . . . 65 12.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 65 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 65
A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 66 A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 66
A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 66 A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 66
A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 66 A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 66
A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 66 A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 66
A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 66 A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 66
A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 67 A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 66
A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 67 A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 67
A.8. "error_description" Syntax . . . . . . . . . . . . . . . 67 A.8. "error_description" Syntax . . . . . . . . . . . . . . . 67
A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 67 A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 67
A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 67 A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 67
A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 67 A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 67
A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 68 A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 67
A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 68 A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 68
A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 68 A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 68
A.15. "username" Syntax . . . . . . . . . . . . . . . . . . . . 68 A.15. "username" Syntax . . . . . . . . . . . . . . . . . . . . 68
A.16. "password" Syntax . . . . . . . . . . . . . . . . . . . . 68 A.16. "password" Syntax . . . . . . . . . . . . . . . . . . . . 68
A.17. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 68 A.17. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 68
A.18. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 69 A.18. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 68
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 69 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 68
Appendix C. Editor's Notes . . . . . . . . . . . . . . . . . . . 70 Appendix C. Editor's Notes . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 16, line 9 skipping to change at page 16, line 9
on public client authentication for the purpose of identifying the on public client authentication for the purpose of identifying the
client. client.
The client MUST NOT use more than one authentication method in each The client MUST NOT use more than one authentication method in each
request. request.
2.3.1. Client Password 2.3.1. Client Password
Clients in possession of a client password MAY use the HTTP Basic Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with authentication scheme as defined in [RFC2617] to authenticate with
the authorization server. The client identifier is used as the the authorization server. The client identifier is encoded using the
username, and the client password is used as the password. The "application/x-www-form-urlencoded" content-type encoding method
authorization server MUST support the HTTP Basic authentication defined by HTML 4.01 [W3C.REC-html401-19991224] and the encoded value
scheme for authenticating clients which were issued a client is used as the username; the client password is used as the password.
password. The authorization server MUST support the HTTP Basic authentication
scheme for authenticating clients that were issued a client password.
For example (extra line breaks are for display purposes only): For example (extra line breaks are for display purposes only):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Alternatively, the authorization server MAY support including the Alternatively, the authorization server MAY support including the
client credentials in the request body using the following client credentials in the request body using the following
parameters: parameters:
client_id client_id
skipping to change at page 36, line 24 skipping to change at page 36, line 24
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 parameters 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".
username username
REQUIRED. The resource owner username, encoded as UTF-8. REQUIRED. The resource owner username.
password password
REQUIRED. The resource owner password, encoded as UTF-8. REQUIRED. The resource owner password.
scope scope
OPTIONAL. The scope of the access request as described by OPTIONAL. The scope of the access request as described by
Section 3.3. Section 3.3.
If the client type is confidential or the client was issued client If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described client MUST authenticate with the authorization server as described
in Section 3.2.1. in Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
skipping to change at page 43, line 37 skipping to change at page 43, line 37
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 as described by OPTIONAL. The scope of the access request as described by
Section 3.3. The requested scope MUST NOT include any scope Section 3.3. The requested scope MUST NOT include any scope
not originally granted by the resource owner, and if omitted is not originally granted by the resource owner, and if omitted is
treated as equal to the scope originally granted by the treated as equal to the scope originally granted by the
resource owner. resource owner.
Because refresh tokens are typically long-lasting credentials used to Because refresh tokens are typically long-lasting credentials used to
request additional access tokens, the refresh token is bound to the request additional access tokens, the refresh token is bound to the
client which it was issued. If the client type is confidential or client to which it was issued. If the client type is confidential or
the client was issued client credentials (or assigned other the client was issued client credentials (or assigned other
authentication requirements), the client MUST authenticate with the authentication requirements), the client MUST authenticate with the
authorization server as described in Section 3.2.1. authorization server as described in Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
transport-layer security (extra line breaks are for display purposes transport-layer security (extra line breaks are for display purposes
only): only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
skipping to change at page 46, line 8 skipping to change at page 46, line 8
[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 7.2. Error Response
If a resource access request fails, the resource server SHOULD inform If a resource access request fails, the resource server SHOULD inform
the client of the error. While the specific error responses possible the client of the error. While the specifics of such error responses
and methods for transmitting those errors when using any particular are beyond the scope of this specification, this documents
access token type are beyond the scope of this specification, any establishes a common registry in Section 11.4 for error values to be
"error" code values defined for use with OAuth resource access shared among OAuth token authentication schemes.
methods MUST be registered (following the procedures in
Section 11.4).
Specifically, when the OAuth resource access method uses an "error" New authentication schemes designed primarily for OAuth token
result parameter to return an error code value that indicates the authentication SHOULD define a mechanism for providing an error
resource access error encountered, then these error code values MUST status code to the client, in which the error values allowed are
be registered. Values for these "error" codes MUST NOT include registered in the error registry established by this specification.
characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an Such schemes MAY limit the set of valid error codes to a subset of
"error" code value is registered for use by an OAuth resource access the registered values. If the error code is returned using a named
method, should that same code already be registered for use by parameter, the parameter name SHOULD be "error".
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 Other schemes capable of being used for OAuth token authentication,
to "error" code values and not to other means of returning error but not primarily designed for that purpose, MAY bind their error
indications, including HTTP status codes, or other error-related values to the registry in the same manner.
result parameters, such as "error_description", "error_uri", or other
kinds of error status return methods that may be employed by the New authentication schemes MAY choose to also specify the use of the
resource access method. There is no requirement that OAuth resource "error_description" and "error_uri" parameters to return error
access methods employ an "error" parameter. information in a manner parallel to their usage in this
specification.
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
skipping to change at page 50, line 14 skipping to change at page 50, line 6
10. Security Considerations 10. Security Considerations
As a flexible and extensible framework, OAuth's security As a flexible and extensible framework, OAuth's security
considerations depend on many factors. The following sections considerations depend on many factors. The following sections
provide implementers with security guidelines focused on the three provide implementers with security guidelines focused on the three
client profiles described in Section 2.1: web application, user- client profiles described in Section 2.1: web application, user-
agent-based application, and native application. agent-based application, and native application.
A comprehensive OAuth security model and analysis, as well as A comprehensive OAuth security model and analysis, as well as
background for the protocol design is provided by background for the protocol design, is provided by
[I-D.ietf-oauth-v2-threatmodel]. [I-D.ietf-oauth-v2-threatmodel].
10.1. Client Authentication 10.1. Client Authentication
The authorization server establishes client credentials with web The authorization server establishes client credentials with web
application clients for the purpose of client authentication. The application clients for the purpose of client authentication. The
authorization server is encouraged to consider stronger client authorization server is encouraged to consider stronger client
authentication means than a client password. Web application clients authentication means than a client password. Web application clients
MUST ensure confidentiality of client passwords and other client MUST ensure confidentiality of client passwords and other client
credentials. credentials.
skipping to change at page 63, line 24 skipping to change at page 63, line 13
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
11.4.1. Registration Template 11.4.1. Registration Template
Error name: Error name:
The name requested (e.g., "example"). The name requested (e.g., "example"). Values for the error name
MUST NOT include characters outside the set %x20-21 / %x23-5B /
%x5D-7E.
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), token error response (Section 5.2), or resource (Section 4.2.2.1), token error response (Section 5.2), or resource
access error response (Section 7.2). 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:
skipping to change at page 65, line 23 skipping to change at page 65, line 15
7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
progress), March 2012. 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-12 (work in OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in
progress), May 2012. 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
Authorization Protocol: Bearer Tokens", Authorization Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-19 (work in progress), draft-ietf-oauth-v2-bearer-20 (work in progress),
April 2012. June 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[I-D.ietf-oauth-v2-threatmodel] [I-D.ietf-oauth-v2-threatmodel]
McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", Threat Model and Security Considerations",
draft-ietf-oauth-v2-threatmodel-02 (work in progress), draft-ietf-oauth-v2-threatmodel-05 (work in progress),
February 2012. May 2012.
[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 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
This section provides 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 descriptions for the elements defined in this specification using the
notation of [RFC5234]. Elements are presented in the order first notation of [RFC5234]. Elements are presented in the order first
defined. defined.
Some of the definitions that follow use the "URI-reference" Some of the definitions that follow use the "URI-reference"
definition from [RFC3986]. definition from [RFC3986].
Some of the definitions that follow use these common definitions: Some of the definitions that follow use these common definitions:
VSCHAR = %20-7E VSCHAR = %20-7E
NQCHAR = %x21 / %x23-5B / %x5D-7E NQCHAR = %x21 / %x23-5B / %x5D-7E
NQSCHAR = %x20-21 / %x23-5B / %x5D-7E NQSCHAR = %x20-21 / %x23-5B / %x5D-7E
UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
A.1. "client_id" Syntax A.1. "client_id" Syntax
The "client_id" element is defined in Section 2.3.1: The "client_id" element is defined in Section 2.3.1:
client-id = *VSCHAR client-id = *VSCHAR
(This matches the "userid" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.2. "client_secret" Syntax A.2. "client_secret" Syntax
The "client_secret" element is defined in Section 2.3.1: The "client_secret" element is defined in Section 2.3.1:
client-secret = *VSCHAR client-secret = *VSCHAR
(This matches the "password" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.3. "response_type" Syntax A.3. "response_type" Syntax
The "response_type" element is defined in Section 3.1.1 and The "response_type" element is defined in Section 3.1.1 and
Section 8.4: Section 8.4:
response-type = response-name *( SP response-name ) response-type = response-name *( SP response-name )
response-name = 1*response-char response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA response-char = "_" / DIGIT / ALPHA
A.4. "scope" Syntax A.4. "scope" Syntax
skipping to change at page 68, line 31 skipping to change at page 68, line 24
A.14. "expires_in" Syntax A.14. "expires_in" Syntax
The "expires_in" element is defined in Section 4.2.2 and Section 5.1: The "expires_in" element is defined in Section 4.2.2 and Section 5.1:
expires-in = 1*DIGIT expires-in = 1*DIGIT
A.15. "username" Syntax A.15. "username" Syntax
The "username" element is defined in Section 4.3.2: The "username" element is defined in Section 4.3.2:
username = *( %x20-39 / %x3B-7E ) username = *UNICODENOCTRLCHAR
(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 A.16. "password" Syntax
The "password" element is defined in Section 4.3.2: The "password" element is defined in Section 4.3.2:
password = *VSCHAR password = *UNICODENOCTRLCHAR
(This matches the "password" definition in the HTTP Basic
Authentication Scheme [RFC2617].)
A.17. "refresh_token" Syntax A.17. "refresh_token" Syntax
The "refresh_token" element is defined in Section 5.1 and Section 6: The "refresh_token" element is defined in Section 5.1 and Section 6:
refresh-token = 1*VSCHAR refresh-token = 1*VSCHAR
A.18. Endpoint Parameter Syntax A.18. Endpoint Parameter Syntax
The syntax for new endpoint parameters is defined in Section 8.2: The syntax for new endpoint parameters is defined in Section 8.2:
skipping to change at page 69, line 50 skipping to change at page 69, line 35
de hOra, Andre DeMarre, Brian Eaton, Wolter Eldering, Brian Ellin, de hOra, Andre DeMarre, Brian Eaton, Wolter Eldering, Brian Ellin,
Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan
Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin
Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, Terry Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, Terry
Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus
Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen,
Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao,
William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,
Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius
Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith,
Haibin Song, Niv Steingarten, Christian Stubner, Jeremy Suriel, Paul Haibin Song, Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul
Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin
Tse, Nick Walker, Shane Weeden, and Skylar Woodward. Tse, Nick Walker, Shane Weeden, and Skylar Woodward.
This document was produced under the chairmanship of Blaine Cook, This document was produced under the chairmanship of Blaine Cook,
Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
The area directors included Lisa Dusseault, Peter Saint-Andre, and The area directors included Lisa Dusseault, Peter Saint-Andre, and
Stephen Farrell. Stephen Farrell.
Appendix C. Editor's Notes Appendix C. Editor's Notes
 End of changes. 32 change blocks. 
76 lines changed or deleted 61 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/