< draft-ietf-oauth-v2-21.txt   draft-ietf-oauth-v2-22.txt >
Network Working Group E. Hammer-Lahav, Ed. Network Working Group E. Hammer-Lahav, Ed.
Internet-Draft Yahoo! Internet-Draft Yahoo!
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) D. Recordon
Intended status: Standards Track Facebook Intended status: Standards Track Facebook
Expires: March 8, 2012 D. Hardt Expires: March 25, 2012 D. Hardt
Microsoft Microsoft
September 5, 2011 September 22, 2011
The OAuth 2.0 Authorization Protocol The OAuth 2.0 Authorization Protocol
draft-ietf-oauth-v2-21 draft-ietf-oauth-v2-22
Abstract Abstract
The OAuth 2.0 authorization protocol enables a third-party The OAuth 2.0 authorization protocol 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. third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2012. This Internet-Draft will expire on March 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 7 1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 7
1.3.1. Authorization Code . . . . . . . . . . . . . . . . . . 7 1.3.1. Authorization Code . . . . . . . . . . . . . . . . . . 7
1.3.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3. Resource Owner Password Credentials . . . . . . . . . 8 1.3.3. Resource Owner Password Credentials . . . . . . . . . 8
1.3.4. Client Credentials . . . . . . . . . . . . . . . . . . 9 1.3.4. Client Credentials . . . . . . . . . . . . . . . . . . 8
1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Notational Conventions . . . . . . . . . . . . . . . . . 11 1.6. Notational Conventions . . . . . . . . . . . . . . . . . 11
2. Client Registration . . . . . . . . . . . . . . . . . . . . . 11 2. Client Registration . . . . . . . . . . . . . . . . . . . . . 11
2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 13 2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 13
2.3. Client Authentication . . . . . . . . . . . . . . . . . . 13 2.3. Client Authentication . . . . . . . . . . . . . . . . . . 13
2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 14 2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 13
2.3.2. Other Authentication Methods . . . . . . . . . . . . . 15 2.3.2. Other Authentication Methods . . . . . . . . . . . . . 14
2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 15 2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 15
3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 15 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 15 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 15
3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 16 3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 16
3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 18 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Client Authentication . . . . . . . . . . . . . . . . 19 3.2.1. Client Authentication . . . . . . . . . . . . . . . . 19
3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 20 3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 20
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 20 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 20
4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 20 4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 20
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 22 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 22
4.1.2. Authorization Response . . . . . . . . . . . . . . . . 23 4.1.2. Authorization Response . . . . . . . . . . . . . . . . 23
4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 25 4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 25
4.1.4. Access Token Response . . . . . . . . . . . . . . . . 26 4.1.4. Access Token Response . . . . . . . . . . . . . . . . 26
4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 27 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Authorization Request . . . . . . . . . . . . . . . . 29 4.2.1. Authorization Request . . . . . . . . . . . . . . . . 28
4.2.2. Access Token Response . . . . . . . . . . . . . . . . 30 4.2.2. Access Token Response . . . . . . . . . . . . . . . . 29
4.3. Resource Owner Password Credentials . . . . . . . . . . . 32 4.3. Resource Owner Password Credentials . . . . . . . . . . . 32
4.3.1. Authorization Request and Response . . . . . . . . . . 33 4.3.1. Authorization Request and Response . . . . . . . . . . 33
4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 33 4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 33
4.3.3. Access Token Response . . . . . . . . . . . . . . . . 34 4.3.3. Access Token Response . . . . . . . . . . . . . . . . 34
4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 35 4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 34
4.4.1. Authorization Request and Response . . . . . . . . . . 36 4.4.1. Authorization Request and Response . . . . . . . . . . 35
4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 36 4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 35
4.4.3. Access Token Response . . . . . . . . . . . . . . . . 36 4.4.3. Access Token Response . . . . . . . . . . . . . . . . 36
4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 37 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 36
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 37 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 37
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 38 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 37
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 39 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 38
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 40 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 40
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 42 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 41
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 42 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 41
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 43 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 42
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 44 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 43
8.3. Defining New Authorization Grant Types . . . . . . . . . 44 8.3. Defining New Authorization Grant Types . . . . . . . . . 43
8.4. Defining New Authorization Endpoint Response Types . . . 44 8.4. Defining New Authorization Endpoint Response Types . . . 43
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 45 8.5. Defining Additional Error Codes . . . . . . . . . . . . . 44
9. Native Applications . . . . . . . . . . . . . . . . . . . . . 45 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
10.1. Client Authentication . . . . . . . . . . . . . . . . . . 47 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 46
10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 47 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 46
10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 48 10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 47
10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 48 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 47
10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 49 10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 48
10.6. Authorization Code Redirection URI Manipulation . . . . . 49 10.6. Authorization Code Redirection URI Manipulation . . . . . 48
10.7. Resource Owner Password Credentials . . . . . . . . . . . 50 10.7. Resource Owner Password Credentials . . . . . . . . . . . 49
10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 51 10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 50
10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 51 10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 50
10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 51 10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 50
10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 51 10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 50
10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 52 10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 51
10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 53 10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 52
10.14. Code Injection and Input Validation . . . . . . . . . . . 53 10.14. Code Injection and Input Validation . . . . . . . . . . . 52
10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 53 10.15. Open Redirectors . . . . . . . . . . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 54 11.1. The OAuth Access Token Type Registry . . . . . . . . . . 53
11.1.1. Registration Template . . . . . . . . . . . . . . . . 54 11.1.1. Registration Template . . . . . . . . . . . . . . . . 53
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 55 11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 54
11.2.1. Registration Template . . . . . . . . . . . . . . . . 56 11.2.1. Registration Template . . . . . . . . . . . . . . . . 55
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 56 11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 55
11.3. The OAuth Authorization Endpoint Response Type 11.3. The OAuth Authorization Endpoint Response Type
Registry . . . . . . . . . . . . . . . . . . . . . . . . 58 Registry . . . . . . . . . . . . . . . . . . . . . . . . 57
11.3.1. Registration Template . . . . . . . . . . . . . . . . 59 11.3.1. Registration Template . . . . . . . . . . . . . . . . 58
11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 59 11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 58
11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 59 11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 58
11.4.1. Registration Template . . . . . . . . . . . . . . . . 60 11.4.1. Registration Template . . . . . . . . . . . . . . . . 59
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 61 Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 60
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.1. Normative References . . . . . . . . . . . . . . . . . . 62 13.1. Normative References . . . . . . . . . . . . . . . . . . 61
13.2. Informative References . . . . . . . . . . . . . . . . . 63 13.2. Informative References . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
accesses a protected resource on the server by authenticating with requests an access restricted resource (protected resource) on the
the server using the resource owner's credentials. In order to server by authenticating with the server using the resource owner's
provide third-party applications access to protected resources, the credentials. In order to provide third-party applications access to
resource owner shares its credentials with the third-party. This restricted resources, the resource owner shares its credentials with
creates several problems and limitations: the third-party. This creates several problems and limitations:
o Third-party applications are required to store the resource o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in clear- owner's credentials for future use, typically a password in clear-
text. text.
o Servers are required to support password authentication, despite o Servers are required to support password authentication, despite
the security weaknesses created by passwords. the security weaknesses created by passwords.
o Third-party applications gain overly broad access to the resource o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of ability to restrict duration or access to a limited subset of
resources. resources.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
password with the printing service. Instead, she authenticates password with the printing service. Instead, she authenticates
directly with a server trusted by the photo sharing service directly with a server trusted by the photo sharing service
(authorization server) which issues the printing service delegation- (authorization server) which issues the printing service delegation-
specific credentials (access token). specific credentials (access token).
This specification is designed for use with HTTP [RFC2616]. The use This specification is designed for use with HTTP [RFC2616]. The use
of OAuth with any transport protocol other than HTTP is undefined. of OAuth with any transport protocol other than HTTP is undefined.
1.1. Roles 1.1. Roles
OAuth includes four roles working together to grant and provide OAuth defines four roles:
access to protected resources - access restricted resources requiring
authentication:
resource owner resource owner
An entity capable of granting access to a protected resource (e.g. An entity capable of granting access to a protected resource (e.g.
end-user). end-user).
resource server resource server
The server hosting the protected resources, capable of accepting The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens. and responding to protected resource requests using access tokens.
client client
An application making protected resource requests on behalf of the An application making protected resource requests on behalf of the
resource owner and with its authorization. resource owner and with its authorization.
skipping to change at page 7, line 4 skipping to change at page 6, line 48
| |--(C)-- Authorization Grant -->| Authorization | | |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server | | Client | | Server |
| |<-(D)----- Access Token -------| | | |<-(D)----- Access Token -------| |
| | +---------------+ | | +---------------+
| | | |
| | +---------------+ | | +---------------+
| |--(E)----- Access Token ------>| Resource | | |--(E)----- Access Token ------>| Resource |
| | | Server | | | | Server |
| |<-(F)--- Protected Resource ---| | | |<-(F)--- Protected Resource ---| |
+--------+ +---------------+ +--------+ +---------------+
Figure 1: Abstract Protocol Flow Figure 1: Abstract Protocol Flow
The abstract flow illustrated in Figure 1 describes the interaction The abstract flow illustrated in Figure 1 describes the interaction
between the four roles and includes the following steps: between the four roles and includes the following steps:
(A) The client requests authorization from the resource owner. The (A) The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via an intermediary such as (as shown), or preferably indirectly via the authorization
an authorization server. server as an intermediary.
(B) The client receives an authorization grant which is a credential (B) The client receives an authorization grant which is a credential
representing the resource owner's authorization, expressed using representing the resource owner's authorization, expressed using
one of four grant types defined in this specification or using one of four grant types defined in this specification or using
an extension grant type. The authorization grant type depends an extension grant type. The authorization grant type depends
on the method used by the client to request authorization and on the method used by the client to request authorization and
the types supported by the authorization server. the types supported by the authorization server.
(C) The client requests an access token by authenticating with the (C) The client requests an access token by authenticating with the
authorization server and presenting the authorization grant. authorization server and presenting the authorization grant.
(D) The authorization server authenticates the client and validates (D) The authorization server authenticates the client and validates
the authorization grant, and if valid issues an access token. the authorization grant, and if valid issues an access token.
skipping to change at page 8, line 7 skipping to change at page 8, line 4
owner back to the client with the authorization code. owner back to the client with the authorization code.
Before directing the resource owner back to the client with the Before directing the resource owner back to the client with the
authorization code, the authorization server authenticates the authorization code, the authorization server authenticates the
resource owner and obtains authorization. Because the resource owner resource owner and obtains authorization. Because the resource owner
only authenticates with the authorization server, the resource only authenticates with the authorization server, the resource
owner's credentials are never shared with the client. owner's credentials are never shared with the client.
The authorization code provides a few important security benefits The authorization code provides a few important security benefits
such as the ability to authenticate the client, and the transmission such as the ability to authenticate the client, and the transmission
of the the access token directly to the client without passing it of the access token directly to the client without passing it through
through the resource owner's user-agnet, potentially exposing it to the resource owner's user-agent, potentially exposing it to others,
others, including the resource owner. including the resource owner.
1.3.2. Implicit 1.3.2. Implicit
The implicit grant is a simplified authorization code flow optimized The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such for clients implemented in a browser using a scripting language such
as JavaScript. In the implicit flow, instead of issuing the client as JavaScript. In the implicit flow, instead of issuing the client
an authorization code, the client is issued an access token directly an authorization code, the client is issued an access token directly
(as the result of the resource owner authorization). The grant type (as the result of the resource owner authorization). The grant type
is implicit as no intermediate credentials (such as an authorization is implicit as no intermediate credentials (such as an authorization
code) are issued (and later used to obtain an access token). code) are issued (and later used to obtain an access token).
When issuing an implicit grant, the authorization server does not When issuing an implicit grant, the authorization server does not
authenticate the client and in some cases, the client identity can be authenticate the client. In some cases, the client identity can be
verified via the redirection URI used to deliver the access token to verified via the redirection URI used to deliver the access token to
the client. The access token may be exposed to the resource owner or the client. The access token may be exposed to the resource owner or
other applications with access to the resource owner's user-agent. other applications with access to the resource owner's user-agent.
Implicit grants improve the responsiveness and efficiency of some Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application) clients (such as a client implemented as an in-browser application)
since it reduces the number of round trips required to obtain an since it reduces the number of round trips required to obtain an
access token. However, this convenience should be weighed against access token. However, this convenience should be weighed against
the security implications of using implicit grants, especially when the security implications of using implicit grants, especially when
the authorization code grant type is available. the authorization code grant type is available.
1.3.3. Resource Owner Password Credentials 1.3.3. Resource Owner Password Credentials
The resource owner password credentials (e.g. a username and The resource owner password credentials (i.e. username and password)
password) can be used directly as an authorization grant to obtain an can be used directly as an authorization grant to obtain an access
access token. The credentials should only be used when there is a token. The credentials should only be used when there is a high
high degree of trust between the resource owner and the client (e.g. degree of trust between the resource owner and the client (e.g. its
its device operating system or a highly privileged application), and device operating system or a highly privileged application), and when
when other authorization grant types are not available (such as an other authorization grant types are not available (such as an
authorization code). authorization code).
Even though this grant type requires direct client access to the Even though this grant type requires direct client access to the
resource owner credentials, the resource owner credentials are used resource owner credentials, the resource owner credentials are used
for a single request and are exchanged for an access token. This for a single request and are exchanged for an access token. This
grant type can eliminate the need for the client to store the grant type can eliminate the need for the client to store the
resource owner credentials for future use, by exchanging the resource owner credentials for future use, by exchanging the
credentials with a long-lived access token or refresh token. credentials with a long-lived access token or refresh token.
1.3.4. Client Credentials 1.3.4. Client Credentials
skipping to change at page 10, line 5 skipping to change at page 9, line 49
this specification and are defined by companion specifications. this specification and are defined by companion specifications.
1.5. Refresh Token 1.5. Refresh Token
Refresh tokens are credentials used to obtain access tokens. Refresh Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional and is included when owner). Issuing a refresh token is optional. If the authorization
issuing an access token. server issues a refresh token, it is included when issuing an access
token.
A refresh token is a string representing the authorization granted to A refresh token is a string representing the authorization granted to
the client by the resource owner. The string is usually opaque to the client by the resource owner. The string is usually opaque to
the client. The token denotes an identifier used to retrieve the the client. The token denotes an identifier used to retrieve the
authorization information. Unlike access tokens, refresh tokens are authorization information. Unlike access tokens, refresh tokens are
intended for use only with authorization servers and are never sent intended for use only with authorization servers and are never sent
to resource servers. to resource servers.
+--------+ +---------------+ +--------+ +---------------+
| |--(A)------- Authorization Grant --------->| | | |--(A)------- Authorization Grant --------->| |
skipping to change at page 12, line 32 skipping to change at page 12, line 28
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
restricted access to the client credentials), or capable of secure restricted access to the client credentials), or capable of secure
client authentication using other means. client authentication using other means.
public public
Clients incapable of maintaining the confidentiality of their Clients incapable of maintaining the confidentiality of their
credentials (e.g. clients executing on the resource owner's device credentials (e.g. clients executing on the resource owner's device
such as an installed native application or a web browser-based such as an installed native application or a web browser-based
application), and incapable of secure client authentication via application), and incapable of secure client authentication via
any other mean. any other means.
The client type designation is based on the authorization server's The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure definition of secure authentication and its acceptable exposure
levels of client credentials. levels of client credentials.
This specification has been designed around the following client This specification has been designed around the following client
profiles: profiles:
web application web application
A web application is a confidential client running on a web A web application is a confidential client running on a web
skipping to change at page 13, line 4 skipping to change at page 12, line 44
This specification has been designed around the following client This specification has been designed around the following client
profiles: profiles:
web application web application
A web application is a confidential client running on a web A web application is a confidential client running on a web
server. Resource owners access the client via an HTML user server. Resource owners access the client via an HTML user
interface rendered in a user-agent on the resource owner's device. interface rendered in a user-agent on the resource owner's device.
The client credentials as well as any access token issued to the The client credentials as well as any access token issued to the
client are stored on the web server and are not exposed to or client are stored on the web server and are not exposed to or
accessible by the resource owner. accessible by the resource owner.
user-agent-based application user-agent-based application
A user-agent-based application is a public client in which the A user-agent-based application is a public client in which the
client code is downloaded from a web server and executes within a client code is downloaded from a web server and executes within a
user-agent (e.g. web browser) on the resource owner's device. user-agent (e.g. web browser) on the resource owner's device.
Protocol data and credentials are easily accessible (and often Protocol data and credentials are easily accessible (and often
visible) to the resource owner. Since such applications reside visible) to the resource owner. Since such applications reside
within the user-agent, they can make seamless use of the user- within the user-agent, they can make seamless use of the user-
agent capabilities when requesting authorization. agent capabilities when requesting authorization.
native application native application
A native application is a public client installed and executed on A native application is a public client installed and executed on
the resource owner's device. Protocol data and credentials are the resource owner's device. Protocol data and credentials are
accessible to the resource owner. It is assumed that any client accessible to the resource owner. It is assumed that any client
authentication credentials included in the application can be authentication credentials included in the application can be
extracted. On the other hand, dynamically issued credentials such extracted. On the other hand, dynamically issued credentials such
access tokens or refresh tokens, can receive an acceptable level access tokens or refresh tokens can receive an acceptable level of
of protection. At a minimum, these credentials are protected from protection. At a minimum, these credentials are protected from
hostile servers which the application may interact with. On some hostile servers which the application may interact with. On some
platform these credentials might be protected from other platform these credentials might be protected from other
applications residing on the same device. applications residing on 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
skipping to change at page 15, line 46 skipping to change at page 15, line 37
3.1. Authorization Endpoint 3.1. Authorization Endpoint
The authorization endpoint is used to interact with the resource The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant. The authorization server owner and obtain an authorization grant. The authorization server
MUST first verify the identity of the resource owner. The way in MUST first verify the identity of the resource owner. The way in
which the authorization server authenticates the resource owner (e.g. which the authorization server authenticates the resource owner (e.g.
username and password login, session cookies) is beyond the scope of username and password login, session cookies) is beyond the scope of
this specification. this specification.
The means through which the client obtains the location of the The means through which the client obtains the location of the
authorization endpoint are beyond the scope of this specification but authorization endpoint are beyond the scope of this specification,
the location is typically provided in the service documentation. but the location is typically provided in the service documentation.
The endpoint URI MAY include an "application/x-www-form-urlencoded" The endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted ([W3C.REC-html401-19991224]) query component ([RFC3986] formatted ([W3C.REC-html401-19991224]) query component ([RFC3986]
section 3.4), which MUST be retained when adding additional query section 3.4), which MUST be retained when adding additional query
parameters. The endpoint URI MUST NOT include a fragment component. parameters. The endpoint URI MUST NOT include a fragment component.
Since requests to the authorization endpoint result in user Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in the authentication and the transmission of clear-text credentials (in the
HTTP response), the authorization server MUST require the use of a HTTP response), the authorization server MUST require the use of a
transport-layer security mechanism when sending requests to the transport-layer security mechanism when sending requests to the
skipping to change at page 19, line 36 skipping to change at page 19, line 28
requests. requests.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server SHOULD ignore omitted from the request. The authorization server SHOULD ignore
unrecognized request parameters. Request and response parameters unrecognized request parameters. Request and response parameters
MUST NOT be included more than once. MUST NOT be included more than once.
3.2.1. Client Authentication 3.2.1. Client Authentication
Confidential clients, clients issued client credentials, or clients Confidential clients, clients issued client credentials, or clients
assigned other authentication requirements, MUST authenticate with assigned other authentication requirements MUST authenticate with the
the authorization server as described in Section 2.3 when making authorization server as described in Section 2.3 when making requests
requests to the token endpoint. Client authentication is used for: to the token endpoint. Client authentication is used for:
o Enforcing the binding of refresh tokens and authorization codes to o Enforcing the binding of refresh tokens and authorization codes to
the client they are issued. Client authentication is critical the client they are issued. Client authentication is critical
when an authorization code is transmitted to the redirection when an authorization code is transmitted to the redirection
endpoint over an insecure channel, or when the redirection URI has endpoint over an insecure channel, or when the redirection URI has
not been registered in full. not been registered in full.
o Recovering from a compromised client by disabling the client or o Recovering from a compromised client by disabling the client or
changing its credentials, thus preventing an attacker from abusing changing its credentials, thus preventing an attacker from abusing
stolen refresh tokens. Changing a single set of client stolen refresh tokens. Changing a single set of client
credentials is significantly faster than revoking an entire set of credentials is significantly faster than revoking an entire set of
skipping to change at page 22, line 4 skipping to change at page 21, line 43
The flow illustrated in Figure 3 includes the following steps: The flow illustrated in Figure 3 includes the following steps:
(A) The client initiates the flow by directing the resource owner's (A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied). user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via (B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner the user-agent) and establishes whether the resource owner
grants or denies the client's access request. grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization (C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the server redirects the user-agent back to the client using the
redirection URI provided earlier. The redirection URI includes redirection URI provided earlier (in the request or during
an authorization code and any local state provided by the client client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier. earlier.
(D) The client requests an access token from the authorization (D) The client requests an access token from the authorization
server's token endpoint by including the authorization code server's token endpoint by including the authorization code
received in the previous step. When making the request, the received in the previous step. When making the request, the
client authenticates with the authorization server. The client client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization includes the redirection URI used to obtain the authorization
code for verification. code for verification.
(E) The authorization server authenticates the client, validates the (E) The authorization server authenticates the client, validates the
authorization code, and ensures the redirection URI received authorization code, and ensures the redirection URI received
matches the URI used to redirect the client in step (C). If matches the URI used to redirect the client in step (C). If
valid, responds back with an access token and optional refresh valid, the authorization server responds back with an access
token. token and optional refresh token.
4.1.1. Authorization Request 4.1.1. Authorization Request
The client constructs the request URI by adding the following The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI parameters to the query component of the authorization endpoint URI
using the "application/x-www-form-urlencoded" format as defined by using the "application/x-www-form-urlencoded" format as defined by
[W3C.REC-html401-19991224]: [W3C.REC-html401-19991224]:
response_type response_type
REQUIRED. Value MUST be set to "code". REQUIRED. Value MUST be set to "code".
skipping to change at page 23, line 36 skipping to change at page 23, line 28
If the resource owner grants the access request, the authorization If the resource owner grants the access request, the authorization
server issues an authorization code and delivers it to the client by server issues an authorization code and delivers it to the client by
adding the following parameters to the query component of the adding the following parameters to the query component of the
redirection URI using the "application/x-www-form-urlencoded" format: redirection URI using the "application/x-www-form-urlencoded" format:
code code
REQUIRED. The authorization code generated by the REQUIRED. The authorization code generated by the
authorization server. The authorization code MUST expire authorization server. The authorization code MUST expire
shortly after it is issued to mitigate the risk of leaks. A shortly after it is issued to mitigate the risk of leaks. A
maximum authorization code lifetime of 10 minutes is maximum authorization code lifetime of 10 minutes is
RECOMMENDED. The client MUST NOT reuse the authorization code. RECOMMENDED. The client MUST NOT use the authorization code
If an authorization code is used more than once, the more than once. If an authorization code is used more than
authorization server SHOULD attempt to revoke all tokens once, the authorization server MUST deny the request and SHOULD
previously issued based on that authorization code. The attempt to revoke all tokens previously issued based on that
authorization code is bound to the client identifier and authorization code. The authorization code is bound to the
redirection URI. client identifier and redirection URI.
state state
REQUIRED if the "state" parameter was present in the client REQUIRED if the "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. The exact value received from the
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?code=SplxlOBeZQQYbYS6WxSbIA Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz &state=xyz
The client SHOULD ignore unrecognized response parameters. The The client SHOULD ignore unrecognized response parameters. The
authorization code string size is left undefined by this authorization code string size is left undefined by this
skipping to change at page 24, line 36 skipping to change at page 24, line 23
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
unsupported parameter or parameter value, or is otherwise unsupported parameter value, or is otherwise malformed.
malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an authorization The client is not authorized to request an authorization
code using this method. code using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
request. request.
unsupported_response_type unsupported_response_type
The authorization server does not support obtaining an The authorization server does not support obtaining an
authorization code using this method. authorization code using this method.
invalid_scope invalid_scope
The requested scope is invalid, unknown, or malformed. The requested scope is invalid, unknown, or malformed.
server_error server_error
The authorization server encountered an unexpected The authorization server encountered an unexpected
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.
error_description error_description
skipping to change at page 25, line 22 skipping to change at page 25, line 4
the request due to a temporary overloading or maintenance the request due to a temporary overloading or maintenance
of the server. of the server.
error_description error_description
OPTIONAL. A human-readable UTF-8 encoded text providing OPTIONAL. A human-readable UTF-8 encoded 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.
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.
state state
REQUIRED if a valid "state" parameter was present in the client REQUIRED if a valid "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. The exact value received from the
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
4.1.3. Access Token Request 4.1.3. Access Token Request
The client makes a request to the token endpoint by adding the The client makes a request to the token endpoint by adding the
following 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 "authorization_code". REQUIRED. Value MUST be set to "authorization_code".
code code
REQUIRED. The authorization code received from the REQUIRED. The authorization code received from the
authorization server. authorization server.
redirect_uri redirect_uri
REQUIRED, if the "redirect_uri" parameter was included in the REQUIRED, if the "redirect_uri" parameter was included in the
authorization request described in Section 4.1.1, and their authorization request as described in Section 4.1.1, and their
values MUST be identical. values MUST be identical.
If the client type is confidential or was issued client credentials If the client type is confidential or the client was issued client
(or assigned other authentication requirements), the client MUST credentials (or assigned other authentication requirements), the
authenticate with the authorization server as described in client MUST authenticate with the authorization server as described
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
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
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST: The authorization server MUST:
o require client authentication for confidential clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client that was issued client credentials (or with other
requirements), authentication requirements),
o authenticate the client if client authentication is included and o authenticate the client if client authentication is included and
ensure the authorization code was issued to the authenticated ensure the authorization code was issued to the authenticated
client, client,
o verify that the authorization code is valid, and o verify that the authorization code is valid, and
o ensure that the "redirect_uri" parameter is present if the o ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization "redirect_uri" parameter was included in the initial authorization
request described in Section 4.1.1, and that their values are request as described in Section 4.1.1, and if included ensure
identical. their values are identical.
4.1.4. Access Token Response 4.1.4. Access Token Response
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh authorization server issues an access token and optional refresh
token as described in Section 5.1. If the request client token as described in Section 5.1. If the request client
authentication failed or is invalid, the authorization server returns authentication failed or is invalid, the authorization server returns
an error response as described in Section 5.2. an error response as described in Section 5.2.
An example successful response: An example successful response:
skipping to change at page 30, line 33 skipping to change at page 30, line 4
4.2.2. Access Token Response 4.2.2. Access Token Response
If the resource owner grants the access request, the authorization If the resource owner grants the access request, the authorization
server issues an access token and delivers it to the client by adding server issues an access token and delivers it to the client by adding
the following parameters to the fragment component of the redirection the following parameters to the fragment component of the redirection
URI using the "application/x-www-form-urlencoded" format: URI using the "application/x-www-form-urlencoded" format:
access_token access_token
REQUIRED. The access token issued by the authorization server. REQUIRED. The access token issued by the authorization server.
token_type token_type
REQUIRED. The type of the token issued as described in REQUIRED. The type of the token issued as described in
Section 7.1. Value is case insensitive. Section 7.1. Value is case insensitive.
expires_in expires_in
OPTIONAL. The lifetime in seconds of the access token. For OPTIONAL. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated. expire in one hour from the time the response was generated.
scope scope
OPTIONAL. The scope of the access request as described by OPTIONAL. The scope of the access token as described by
Section 3.3. Section 3.3.
state state
REQUIRED if the "state" parameter was present in the client REQUIRED if the "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. The exact value received from the
the client. client.
The authorization server MUST NOT issue a refresh token.
For example, the authorization server redirects the user-agent by For example, the authorization server redirects the user-agent by
sending the following HTTP response (URI extra line breaks are for sending the following HTTP response (URI extra line breaks are for
display purposes only): display purposes only):
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600 &state=xyz&token_type=example&expires_in=3600
Developers should note that some HTTP client implementations do not Developers should note that some HTTP client implementations do not
skipping to change at page 31, line 43 skipping to change at page 31, line 13
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI, fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following the authorization server informs the client by adding the following
parameters to the fragment component of the redirection URI using the parameters to the fragment component of the redirection URI using the
"application/x-www-form-urlencoded" format: "application/x-www-form-urlencoded" format:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
unsupported parameter or parameter value, or is otherwise unsupported parameter value, or is otherwise malformed.
malformed.
unauthorized_client unauthorized_client
The client is not authorized to request an access token The client is not authorized to request an access token
using this method. using this method.
access_denied access_denied
The resource owner or authorization server denied the The resource owner or authorization server denied the
request. request.
unsupported_response_type unsupported_response_type
The authorization server does not support obtaining an The authorization server does not support obtaining an
access token using this method. access token using this method.
invalid_scope invalid_scope
The requested scope is invalid, unknown, or malformed. The requested scope is invalid, unknown, or malformed.
server_error server_error
The authorization server encountered an unexpected The authorization server encountered an unexpected
skipping to change at page 32, line 30 skipping to change at page 31, line 42
error_description error_description
OPTIONAL. A human-readable UTF-8 encoded text providing OPTIONAL. A human-readable UTF-8 encoded 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.
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.
state state
REQUIRED if a valid "state" parameter was present in the client REQUIRED if a valid "state" parameter was present in the client
authorization request. Set to the exact value received from authorization request. The exact value received from the
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
4.3. Resource Owner Password Credentials 4.3. Resource Owner Password Credentials
The resource owner password credentials grant type is suitable in The resource owner password credentials grant type is suitable in
skipping to change at page 34, line 16 skipping to change at page 33, line 31
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, encoded as UTF-8.
password password
REQUIRED. The resource owner password, encoded as UTF-8. REQUIRED. The resource owner password, encoded as UTF-8.
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 was issued client credentials If the client type is confidential or the client was issued client
(or assigned other authentication requirements), the client MUST credentials (or assigned other authentication requirements), the
authenticate with the authorization server as described in client MUST authenticate with the authorization server as described
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
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
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=password&username=johndoe&password=A3ddj3w grant_type=password&username=johndoe&password=A3ddj3w
The authorization server MUST: The authorization server MUST:
o require client authentication for confidential clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client that was issued client credentials (or with other
requirements), authentication requirements),
o authenticate the client if client authentication is included, and o authenticate the client if client authentication is included, and
o validate the resource owner password credentials. o validate the resource owner password credentials.
Since this access token request utilizes the resource owner's Since this access token request utilizes the resource owner's
password, the authorization server MUST protect the endpoint against password, the authorization server MUST protect the endpoint against
brute force attacks. brute force attacks.
4.3.3. Access Token Response 4.3.3. Access Token Response
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
skipping to change at page 37, line 35 skipping to change at page 36, line 46
For example, to request an access token using a SAML 2.0 assertion For example, to request an access token using a SAML 2.0 assertion
grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
makes the following HTTP request using transport-layer security (line makes the following HTTP request using transport-layer security (line
breaks are for display purposes only): breaks are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh authorization server issues an access token and optional refresh
token as described in Section 5.1. If the request failed client token as described in Section 5.1. If the request failed client
authentication or is invalid, the authorization server returns an authentication or is invalid, the authorization server returns an
error response as described in Section 5.2. error response as described in Section 5.2.
5. Issuing an Access Token 5. Issuing an Access Token
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
skipping to change at page 38, line 29 skipping to change at page 37, line 41
Section 7.1. Value is case insensitive. Section 7.1. Value is case insensitive.
expires_in expires_in
OPTIONAL. The lifetime in seconds of the access token. For OPTIONAL. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated. expire in one hour from the time the response was generated.
refresh_token refresh_token
OPTIONAL. The refresh token which can be used to obtain new OPTIONAL. The refresh token which can be used to obtain new
access tokens using the same authorization grant as described access tokens using the same authorization grant as described
in Section 6. in Section 6.
scope scope
OPTIONAL. The scope of the access request as described by OPTIONAL. The scope of the access token as described by
Section 3.3. Section 3.3.
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.
skipping to change at page 39, line 35 skipping to change at page 38, line 41
5.2. Error Response 5.2. Error Response
The authorization server responds with an HTTP 400 (Bad Request) The authorization server responds with an HTTP 400 (Bad Request)
status code and includes the following parameters with the response: status code and includes the following parameters with the response:
error error
REQUIRED. A single error code from the following: REQUIRED. A single error code from the following:
invalid_request invalid_request
The request is missing a required parameter, includes an The request is missing a required parameter, includes an
unsupported parameter or parameter value, repeats a unsupported parameter value, repeats a parameter,
parameter, includes multiple credentials, utilizes more includes multiple credentials, utilizes more than one
than one mechanism for authenticating the client, or is mechanism for authenticating the client, or is otherwise
otherwise malformed. malformed.
invalid_client invalid_client
Client authentication failed (e.g. unknown client, no Client authentication failed (e.g. unknown client, no
client authentication included, or unsupported client authentication included, or unsupported
authentication method). The authorization server MAY authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization" client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code, and respond with an HTTP 401 (Unauthorized) status code, and
include the "WWW-Authenticate" response header field include the "WWW-Authenticate" response header field
skipping to change at page 40, line 4 skipping to change at page 39, line 9
Client authentication failed (e.g. unknown client, no Client authentication failed (e.g. unknown client, no
client authentication included, or unsupported client authentication included, or unsupported
authentication method). The authorization server MAY authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization" client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code, and respond with an HTTP 401 (Unauthorized) status code, and
include the "WWW-Authenticate" response header field include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client. matching the authentication scheme used by the client.
invalid_grant invalid_grant
The provided authorization grant is invalid, expired, The provided authorization grant (e.g. authorization
revoked, does not match the redirection URI used in the code, resource owner credentials, client credentials) is
authorization request, or was issued to another client. invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
unauthorized_client unauthorized_client
The authenticated client is not authorized to use this The authenticated client is not authorized to use this
authorization grant type. authorization grant type.
unsupported_grant_type unsupported_grant_type
The authorization grant type is not supported by the The authorization grant type is not supported by the
authorization server. authorization server.
invalid_scope invalid_scope
The requested scope is invalid, unknown, malformed, or The requested scope is invalid, unknown, malformed, or
exceeds the scope granted by the resource owner. exceeds the scope granted by the resource owner.
error_description error_description
skipping to change at page 41, line 13 skipping to change at page 40, line 18
client makes a refresh request to the token endpoint by adding the client makes a refresh 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 "refresh_token". REQUIRED. Value MUST be set to "refresh_token".
refresh_token refresh_token
REQUIRED. The refresh token issued to the client. REQUIRED. The refresh token issued to the client.
scope scope
OPTIONAL. The scope of the access request as described by OPTIONAL. The scope of the access request as described by
Section 3.3. The requested scope MUST be equal or lesser than Section 3.3. The requested scope MUST NOT include any scope
the scope originally granted by the resource owner, and if not originally granted by the resource owner, and if omitted is
omitted is treated as equal to the scope originally granted by treated as equal to the scope originally granted by the
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 it was issued. If the client type is confidential or was client it was issued. If the client type is confidential or the
issued client credentials (or assigned other authentication client was issued client credentials (or assigned other
requirements), the client MUST authenticate with the authorization authentication requirements), the client MUST authenticate with the
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
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
The authorization server MUST: The authorization server MUST:
o require client authentication for confidential clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client that was issued client credentials (or with other
requirements), authentication requirements),
o authenticate the client if client authentication is included and o authenticate the client if client authentication is included and
ensure the refresh token was issued to the authenticated client, ensure the refresh token was issued to the authenticated client,
and and
o validate the refresh token. o validate the refresh token.
If valid and authorized, the authorization server issues an access If valid and authorized, the authorization server issues an access
token as described in Section 5.1. If the request failed token as described in Section 5.1. If the request failed
verification or is invalid, the authorization server returns an error verification or is invalid, the authorization server returns an error
response as described in Section 5.2. response as described in Section 5.2.
The authorization server MAY issue a new refresh token, in which case The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old new refresh token. The authorization server MAY revoke the old
skipping to change at page 47, line 48 skipping to change at page 46, line 48
A malicious client can impersonate another client and obtain access A malicious client can impersonate another client and obtain access
to protected resources, if the impersonated client fails to, or is to protected resources, if the impersonated client fails to, or is
unable to, keep its client credentials confidential. unable to, keep its client credentials confidential.
The authorization server MUST authenticate the client whenever The authorization server MUST authenticate the client whenever
possible. If the authorization server cannot authenticate the client possible. If the authorization server cannot authenticate the client
due to the client's nature, the authorization server MUST require the due to the client's nature, the authorization server MUST require the
registration of any redirection URI used for receiving authorization registration of any redirection URI used for receiving authorization
responses, and SHOULD utilize other means to protect resource owners responses, and SHOULD utilize other means to protect resource owners
from such malicious clients. For example, engaging the resource from such malicious clients. For example, the authorization server
owner to assist in identifying the client and its origin. can engage the resource owner to assist in identifying the client and
its origin.
The authorization server SHOULD enforce explicit resource owner The authorization server SHOULD enforce explicit resource owner
authentication and provide the resource owner with information about authentication and provide the resource owner with information about
the client and the requested authorization scope and lifetime. It is the client and the requested authorization scope and lifetime. It is
up to the resource owner to review the information in the context of up to the resource owner to review the information in the context of
the current client, and authorize or deny the request. the current client, and authorize or deny the request.
The authorization server SHOULD NOT process repeated authorization The authorization server SHOULD NOT process repeated authorization
requests automatically (without active resource owner interaction) requests automatically (without active resource owner interaction)
without authenticating the client or relying on other measures to without authenticating the client or relying on other measures to
skipping to change at page 49, line 29 skipping to change at page 48, line 29
The transmission of authorization codes SHOULD be made over a secure The transmission of authorization codes SHOULD be made over a secure
channel, and the client SHOULD implement TLS for use with its channel, and the client SHOULD implement TLS for use with its
redirection URI if the URI identifies a network resource. Effort redirection URI if the URI identifies a network resource. Effort
should be made to keep authorization codes confidential. Since should be made to keep authorization codes confidential. Since
authorization codes are transmitted via user-agent redirections, they authorization codes are transmitted via user-agent redirections, they
could potentially be disclosed through user-agent history and HTTP could potentially be disclosed through user-agent history and HTTP
referrer headers. referrer headers.
Authorization codes operate as plaintext bearer credentials, used to Authorization codes operate as plaintext bearer credentials, used to
verify that the resource owner who granted authorization at the verify that the resource owner who granted authorization at the
authorization server, is the same resource owner returning to the authorization server is the same resource owner returning to the
client to complete the process. Therefore, if the client relies on client to complete the process. Therefore, if the client relies on
the authorization code for its own resource owner authentication, the the authorization code for its own resource owner authentication, the
client redirection endpoint MUST require TLS. client redirection endpoint MUST require TLS.
Authorization codes MUST be short lived and single use. If the Authorization codes MUST be short lived and single use. If the
authorization server observes multiple attempts to exchange an authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server authorization code for an access token, the authorization server
SHOULD attempt to revoke all access tokens already granted based on SHOULD attempt to revoke all access tokens already granted based on
the compromised authorization code. the compromised authorization code.
skipping to change at page 50, line 14 skipping to change at page 49, line 14
An attacker can create an account at a legitimate client and initiate An attacker can create an account at a legitimate client and initiate
the authorization flow. When the attacker is sent to the the authorization flow. When the attacker is sent to the
authorization server to grant access, the attacker grabs the authorization server to grant access, the attacker grabs the
authorization URI provided by the legitimate client, and replaces the authorization URI provided by the legitimate client, and replaces the
client's redirection URI with a URI under the control of the client's redirection URI with a URI under the control of the
attacker. The attacker then tricks the victim into following the attacker. The attacker then tricks the victim into following the
manipulated link to authorize access to the legitimate client. manipulated link to authorize access to the legitimate client.
Once at the authorization server, the victim is prompted with a Once at the authorization server, the victim is prompted with a
normal, valid request on behalf of a legitimate and familiar client, normal, valid request on behalf of a legitimate and trusted client,
and authorizes the request. The victim is then redirected to an and authorizes the request. The victim is then redirected to an
endpoint under the control of the attacker with the authorization endpoint under the control of the attacker with the authorization
code. The attacker completes the authorization flow by sending the code. The attacker completes the authorization flow by sending the
authorization code to the client using the original redirection URI authorization code to the client using the original redirection URI
provided by the client. The client exchanges the authorization code provided by the client. The client exchanges the authorization code
with an access token and links it to the attacker's client account with an access token and links it to the attacker's client account
which can now gain access to the protected resources authorized by which can now gain access to the protected resources authorized by
the victim (via the client). the victim (via the client).
In order to prevent such an attack, the authorization server MUST In order to prevent such an attack, the authorization server MUST
ensure that the redirection URI used to obtain the authorization ensure that the redirection URI used to obtain the authorization code
code, is the same as the redirection URI provided when exchanging the is identical to the redirection URI provided when exchanging the
authorization code for an access token. The authorization server authorization code for an access token. The authorization server
MUST require public clients and SHOULD require confidential clients MUST require public clients and SHOULD require confidential clients
to register their redirection URI and if provided in the request, to register their redirection URIs. If a redirection URI is provided
MUST validate the redirection URI received in the authorization in the request, the authorization server MUST validate it against the
request against the registered value. registered value.
10.7. Resource Owner Password Credentials 10.7. Resource Owner Password Credentials
The resource owner password credentials grant type is often used for The resource owner password credentials grant type is often used for
legacy or migration reasons. It reduces the overall risk of storing legacy or migration reasons. It reduces the overall risk of storing
username and password by the client, but does not eliminate the need username and password by the client, but does not eliminate the need
to expose highly privileged credentials to the client. to expose highly privileged credentials to the client.
This grant type carries a higher risk than other grant types because This grant type carries a higher risk than other grant types because
it maintains the password anti-pattern this protocol seeks to avoid. it maintains the password anti-pattern this protocol seeks to avoid.
skipping to change at page 52, line 25 skipping to change at page 51, line 25
to inject their own authorization code or access token, which can to inject their own authorization code or access token, which can
result in the client using an access token associated with the result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g. save attacker's protected resources rather than the victim's (e.g. save
the victim's bank account information to a protected resource the victim's bank account information to a protected resource
controlled by the attacker). controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI. The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g. a hash of the session the user-agent's authenticated state (e.g. a hash of the session
cookie used to authentication the user-agent). The client SHOULD cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request. authorization server when making an authorization request.
Once authorization has been obtained from the end-user, the Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state" client with the required binding value contained in the "state"
parameter. The binding value enables the client to validate the parameter. The binding value enables the client to verify the
validity of the request by matching the binding value to the user- validity of the request by matching the binding value to the user-
agent's authenticated state. The binding value used for CSRF agent's authenticated state. The binding value used for CSRF
protection MUST contain a non-guessable value, and the user-agent's protection MUST contain a non-guessable value, and the user-agent's
authenticated state (e.g. session cookie, HTML5 local storage) MUST authenticated state (e.g. session cookie, HTML5 local storage) MUST
be kept in a location accessible only to the client and the user- be kept in a location accessible only to the client and the user-
agent (i.e., protected by same-origin policy). agent (i.e., protected by same-origin policy).
A CSRF attack against the against the authorization server's A CSRF attack against the authorization server's authorization
authorization endpoint can result in an attacker obtaining end-user endpoint can result in an attacker obtaining end-user authorization
authorization for a malicious client without involving or alerting for a malicious client without involving or alerting the end-user.
the end-user.
The authorization server MUST implement CSRF protection for its The authorization server MUST implement CSRF protection for its
authorization endpoint, and ensure that a malicious client cannot authorization endpoint, and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of obtain authorization without the awareness and explicit consent of
the resource owner. the resource owner.
10.13. Clickjacking 10.13. Clickjacking
In a clickjacking attack, an attacker registers a legitimate client In a clickjacking attack, an attacker registers a legitimate client
and then constructs a malicious site in which it loads the and then constructs a malicious site in which it loads the
skipping to change at page 53, line 31 skipping to change at page 52, line 31
avoidance of iframes can be enforced by the authorization server avoidance of iframes can be enforced by the authorization server
using the (non-standard) "x-frame-options" header. This header can using the (non-standard) "x-frame-options" header. This header can
have two values, "deny" and "sameorigin", which will block any have two values, "deny" and "sameorigin", which will block any
framing, or framing by sites with a different origin, respectively. framing, or framing by sites with a different origin, respectively.
For older browsers, javascript framebusting techniques can be used For older browsers, javascript framebusting techniques can be used
but may not be effective in all browsers. 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 in which that input can cause variable is used by an application unsanitized and causes
modification of the application logic when used unsanitized. This modification to the application logic. This may allow an attacker to
may allow an attacker to gain access to the application device or its gain access to the application device or its data, cause denial of
data, cause denial of service, or a wide range of malicious side- service, or a wide range of malicious side-effects.
effects.
The Authorization server and client MUST validate and sanitize any The Authorization server and client MUST validate and sanitize any
value received, and in particular, the value of the "state" and value received, and in particular, the value of the "state" and
"redirect_uri" parameters. "redirect_uri" parameters.
10.15. Open Redirectors 10.15. Open Redirectors
The authorization server authorization endpoint and the client The authorization server authorization endpoint and the client
redirection endpoint can be improperly configured and operate as open redirection endpoint can be improperly configured and operate as open
redirectors. An open redirector is an endpoint using a parameter to redirectors. An open redirector is an endpoint using a parameter to
skipping to change at page 54, line 35 skipping to change at page 53, line 34
"Request for access token type: example"). [[ Note to RFC-EDITOR: The "Request for access token type: example"). [[ Note to RFC-EDITOR: The
name of the mailing list should be determined in consultation with name of the mailing list should be determined in consultation with
the IESG and IANA. Suggested name: oauth-ext-review. ]] the IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list and IANA. Denials should include an decision to the review list and IANA. Denials should include an
explanation and, if applicable, suggestions as to how to make the explanation and, if applicable, suggestions as to how to make the
request successful. request successful.
Decisions (or lack thereof) made by the Designated Expert can be Decisions (or lack thereof) made by the Designated Expert(s) can be
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
skipping to change at page 55, line 31 skipping to change at page 54, line 31
including a URI that can be used to retrieve a copy of the including a URI that can be used to retrieve a copy of the
document. An indication of the relevant sections may also be document. An indication of the relevant sections may also be
included, but is not required. included, but is not required.
11.2. The OAuth Parameters Registry 11.2. The OAuth Parameters Registry
This specification establishes the OAuth parameters registry. This specification establishes the OAuth parameters registry.
Additional parameters for inclusion in the authorization endpoint Additional parameters for inclusion in the authorization endpoint
request, the authorization endpoint response, the token endpoint request, the authorization endpoint response, the token endpoint
request, or the token endpoint response, are registered on the advice request, or the token endpoint response are registered on the advice
of one or more Designated Experts (appointed by the IESG or their of one or more Designated Experts (appointed by the IESG or their
delegate), with a Specification Required (using terminology from delegate), with a Specification Required (using terminology from
[RFC5226]). However, to allow for the allocation of values prior to [RFC5226]). However, to allow for the allocation of values prior to
publication, the Designated Expert(s) may approve registration once publication, the Designated Expert(s) may approve registration once
they are satisfied that such a specification will be published. they are satisfied that such a specification will be published.
Registration requests should be sent to the [TBD]@ietf.org mailing Registration requests should be sent to the [TBD]@ietf.org mailing
list for review and comment, with an appropriate subject (e.g., list for review and comment, with an appropriate subject (e.g.,
"Request for parameter: example"). [[ Note to RFC-EDITOR: The name of "Request for parameter: 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. ]]
Within at most 14 days of the request, the Designated Expert(s) will Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list and IANA. Denials should include an decision to the review list and IANA. Denials should include an
explanation and, if applicable, suggestions as to how to make the explanation and, if applicable, suggestions as to how to make the
request successful. request successful.
Decisions (or lack thereof) made by the Designated Expert can be Decisions (or lack thereof) made by the Designated Expert(s) can be
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
skipping to change at page 58, line 49 skipping to change at page 57, line 49
"Request for response type: example"). [[ Note to RFC-EDITOR: The "Request for response type: example"). [[ Note to RFC-EDITOR: The
name of the mailing list should be determined in consultation with name of the mailing list should be determined in consultation with
the IESG and IANA. Suggested name: oauth-ext-review. ]] the IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list and IANA. Denials should include an decision to the review list and IANA. Denials should include an
explanation and, if applicable, suggestions as to how to make the explanation and, if applicable, suggestions as to how to make the
request successful. request successful.
Decisions (or lack thereof) made by the Designated Expert can be Decisions (or lack thereof) made by the Designated Expert(s) can be
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
skipping to change at page 60, line 17 skipping to change at page 59, line 17
"Request for error code: example"). [[ Note to RFC-EDITOR: The name "Request for error code: example"). [[ Note to RFC-EDITOR: The name
of the mailing list should be determined in consultation with the of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: oauth-ext-review. ]] IESG and IANA. Suggested name: oauth-ext-review. ]]
Within at most 14 days of the request, the Designated Expert(s) will Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list and IANA. Denials should include an decision to the review list and IANA. Denials should include an
explanation and, if applicable, suggestions as to how to make the explanation and, if applicable, suggestions as to how to make the
request successful. request successful.
Decisions (or lack thereof) made by the Designated Expert can be Decisions (or lack thereof) made by the Designated Expert(s) can be
first appealed to Application Area Directors (contactable using first appealed to Application Area Directors (contactable using
app-ads@tools.ietf.org email address or directly by looking up their app-ads@tools.ietf.org email address or directly by looking up their
email addresses on http://www.iesg.org/ website) and, if the email addresses on http://www.iesg.org/ website) and, if the
appellant is not satisfied with the response, to the full IESG (using appellant is not satisfied with the response, to the full IESG (using
the iesg@iesg.org mailing list). the iesg@iesg.org mailing list).
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
skipping to change at page 61, line 30 skipping to change at page 60, line 30
Smith. Smith.
The OAuth WRAP specification was edited by Dick Hardt and authored by The OAuth WRAP specification was edited by Dick Hardt and authored by
Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom.
This specification is the work of the OAuth Working Group which This specification is the work of the OAuth Working Group which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
which shaped and formed the final specification: which shaped and formed the final specification:
Michael Adams, Andrew Arnott, Dirk Balfanz, Aiden Bell, Scott Cantor, Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden
Marcos Caceres, Blaine Cook, Brian Campbell, Brian Eaton, Leah Bell, Scott Cantor, Marcos Caceres, Blaine Cook, Brian Campbell,
Culver, Bill de hOra, Brian Eaton, Brian Ellin, Igor Faynberg, George Brian Eaton, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton,
Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, Brent Goldman, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan
Kristoffer Gronowski, Justin Hart, Dick Hardt, Craig Heath, Phil Gilbert, Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin
Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, John
Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf,
Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair
McGloin, Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, Chuck
Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Mortimore, Anthony Nadalin, Justin Richer, Peter Saint-Andre, Nat
Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Niv Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard,
Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Allen Vlad Skvortsov, Justin Smith, Niv Steingarten, Christian Stuebner,
Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward. Jeremy Suriel, Paul Tarjan, Allen Tom, Franklin Tse, Nick Walker,
Shane Weeden, and Skylar Woodward.
Appendix A. Editor's Notes Appendix A. Editor's Notes
While many people contributed to this specification throughout its While many people contributed to this specification throughout its
long journey, the editor would like to acknowledge and thank a few long journey, the editor would like to acknowledge and thank a few
individuals for their outstanding and invaluable efforts leading up individuals for their outstanding and invaluable efforts leading up
to the publication of this specification. It is these individuals to the publication of this specification. It is these individuals
without whom this work would not have existed or reached its without whom this work would not have existed or reached its
successful conclusion. successful conclusion.
skipping to change at page 63, line 17 skipping to change at page 62, line 19
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Hors, A., 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 13.2. Informative References
[I-D.draft-hardt-oauth-01] [I-D.draft-hardt-oauth-01]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
Web Resource Authorization Profiles", January 2010. Web Resource Authorization Profiles", January 2010.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Mortimore, C., "SAML 2.0 Bearer Assertion Grant Type Mortimore, C., "SAML 2.0 Bearer Assertion Profiles for
Profile for OAuth 2.0", draft-ietf-oauth-saml2-bearer-04 OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work in
(work in progress), May 2011. progress), August 2011.
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-06 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-08
(work in progress), June 2011. (work in progress), July 2011.
[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., Barth, A., and B. Adida, "HTTP
Authentication: MAC Access Authentication", Authentication: MAC Access Authentication",
draft-ietf-oauth-v2-http-mac-00 (work in progress), draft-ietf-oauth-v2-http-mac-00 (work in progress),
May 2011. May 2011.
[I-D.ietf-oauth-v2-threatmodel] [I-D.ietf-oauth-v2-threatmodel]
Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", Threat Model and Security Considerations",
 End of changes. 76 change blocks. 
198 lines changed or deleted 203 lines changed or added

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