draft-ietf-oauth-v2-18.txt   draft-ietf-oauth-v2-19.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: January 9, 2012 D. Hardt Expires: January 26, 2012 D. Hardt
Microsoft Microsoft
July 8, 2011 July 25, 2011
The OAuth 2.0 Authorization Protocol The OAuth 2.0 Authorization Protocol
draft-ietf-oauth-v2-18 draft-ietf-oauth-v2-19
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.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 9, 2012. This Internet-Draft will expire on January 26, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 7 1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 8
1.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 7 1.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 8
1.4.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3. Resource Owner Password Credentials . . . . . . . . . 8 1.4.3. Resource Owner Password Credentials . . . . . . . . . 9
1.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 8 1.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 9
1.4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 8 1.4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Notational Conventions . . . . . . . . . . . . . . . . . 10 1.6. Notational Conventions . . . . . . . . . . . . . . . . . 11
2. Client Registration . . . . . . . . . . . . . . . . . . . . . 10 2. Client Registration . . . . . . . . . . . . . . . . . . . . . 11
2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 11 2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Registration Requirements . . . . . . . . . . . . . . . . 11 2.2. Registration Requirements . . . . . . . . . . . . . . . . 13
2.3. Client Identifier . . . . . . . . . . . . . . . . . . . . 11 2.3. Client Identifier . . . . . . . . . . . . . . . . . . . . 13
2.4. Client Authentication . . . . . . . . . . . . . . . . . . 11 2.4. Client Authentication . . . . . . . . . . . . . . . . . . 13
2.4.1. Client Password . . . . . . . . . . . . . . . . . . . 12 2.4.1. Client Password . . . . . . . . . . . . . . . . . . . 14
2.4.2. Other Authentication Methods . . . . . . . . . . . . . 13 2.4.2. Other Authentication Methods . . . . . . . . . . . . . 15
2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 13 2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 15
3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 13 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 13 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 15
3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 14 3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Redirection URI . . . . . . . . . . . . . . . . . . . 15 3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 16
3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 17 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Client Authentication . . . . . . . . . . . . . . . . 17 3.2.1. Client Authentication . . . . . . . . . . . . . . . . 19
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 18 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 19
4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 18 4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 20
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 20 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 21
4.1.2. Authorization Response . . . . . . . . . . . . . . . . 21 4.1.2. Authorization Response . . . . . . . . . . . . . . . . 22
4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 23 4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 24
4.1.4. Access Token Response . . . . . . . . . . . . . . . . 24 4.1.4. Access Token Response . . . . . . . . . . . . . . . . 25
4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 24 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Authorization Request . . . . . . . . . . . . . . . . 27 4.2.1. Authorization Request . . . . . . . . . . . . . . . . 28
4.2.2. Access Token Response . . . . . . . . . . . . . . . . 28 4.2.2. Access Token Response . . . . . . . . . . . . . . . . 29
4.3. Resource Owner Password Credentials . . . . . . . . . . . 30 4.3. Resource Owner Password Credentials . . . . . . . . . . . 31
4.3.1. Authorization Request and Response . . . . . . . . . . 31 4.3.1. Authorization Request and Response . . . . . . . . . . 32
4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 32 4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 33
4.3.3. Access Token Response . . . . . . . . . . . . . . . . 33 4.3.3. Access Token Response . . . . . . . . . . . . . . . . 34
4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 33 4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 34
4.4.1. Authorization Request and Response . . . . . . . . . . 34 4.4.1. Authorization Request and Response . . . . . . . . . . 35
4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 34 4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 35
4.4.3. Access Token Response . . . . . . . . . . . . . . . . 35 4.4.3. Access Token Response . . . . . . . . . . . . . . . . 36
4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 35 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 36
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 36 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 37
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 36 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 37
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 38 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 39
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 39 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 40
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 40 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 41
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 41 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 42
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 42 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 43
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 42 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 43
8.3. Defining New Authorization Grant Types . . . . . . . . . 43 8.3. Defining New Authorization Grant Types . . . . . . . . . 44
8.4. Defining New Authorization Endpoint Response Types . . . 43 8.4. Defining New Authorization Endpoint Response Types . . . 44
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 43 8.5. Defining Additional Error Codes . . . . . . . . . . . . . 44
9. Native Applications . . . . . . . . . . . . . . . . . . . . . 44 9. Native Applications . . . . . . . . . . . . . . . . . . . . . 45
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
10.1. Client Authentication . . . . . . . . . . . . . . . . . . 46 10.1. Client Authentication . . . . . . . . . . . . . . . . . . 46
10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 46 10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 47
10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 47 10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 47
10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 47 10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 48
10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 48 10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 48
10.6. Authorization Code Leakage . . . . . . . . . . . . . . . 48 10.6. Authorization Code Leakage . . . . . . . . . . . . . . . 49
10.7. Resource Owner Password Credentials . . . . . . . . . . . 49 10.7. Resource Owner Password Credentials . . . . . . . . . . . 49
10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 49 10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 50
10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 49 10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 50
10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 49 10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 50
10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 50 10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 50
10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 50 10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 51
10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 51 10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 51
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 10.14. Code Injection and Input Validation . . . . . . . . . . . 52
11.1. The OAuth Access Token Type Registry . . . . . . . . . . 51 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
11.1.1. Registration Template . . . . . . . . . . . . . . . . 52 11.1. The OAuth Access Token Type Registry . . . . . . . . . . 52
11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 52 11.1.1. Registration Template . . . . . . . . . . . . . . . . 53
11.2.1. Registration Template . . . . . . . . . . . . . . . . 53 11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 53
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 53 11.2.1. Registration Template . . . . . . . . . . . . . . . . 54
11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 54
11.3. The OAuth Authorization Endpoint Response Type 11.3. The OAuth Authorization Endpoint Response Type
Registry . . . . . . . . . . . . . . . . . . . . . . . . 55 Registry . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3.1. Registration Template . . . . . . . . . . . . . . . . 56 11.3.1. Registration Template . . . . . . . . . . . . . . . . 57
11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 56 11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 57
11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 57 11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 58
11.4.1. Registration Template . . . . . . . . . . . . . . . . 57 11.4.1. Registration Template . . . . . . . . . . . . . . . . 58
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 59 Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 60
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.1. Normative References . . . . . . . . . . . . . . . . . . 59 13.1. Normative References . . . . . . . . . . . . . . . . . . 60
13.2. Informative References . . . . . . . . . . . . . . . . . 60 13.2. Informative References . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
accesses a protected resource on the server by authenticating with accesses a protected resource on the server by authenticating with
the server using the resource owner's credentials. In order to the server using the resource owner's credentials. In order to
provide third-party applications access to protected resources, the provide third-party applications access to protected resources, the
resource owner shares its credentials with the third-party. This resource owner shares its credentials with the third-party. This
creates several problems and limitations: creates several problems and limitations:
skipping to change at page 10, line 36 skipping to change at page 11, line 36
defined in [RFC4949]. These terms include, but are not limited to, defined in [RFC4949]. These terms include, but are not limited to,
'attack', 'authentication', 'authorization', 'certificate', 'attack', 'authentication', 'authorization', 'certificate',
'confidentiality', 'credential', 'encryption', 'identity', 'sign', 'confidentiality', 'credential', 'encryption', 'identity', 'sign',
'signature', 'trust', 'validate', and 'verify'. 'signature', 'trust', 'validate', and 'verify'.
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
2. Client Registration 2. Client Registration
[[ Pending Consensus ]]
Before initiating the protocol, the client registers with the Before initiating the protocol, the client registers with the
authorization server. The means through which the client registers authorization server. The means through which the client registers
with the authorization server are beyond the scope of this with the authorization server are beyond the scope of this
specification, but typically involve end-user interaction with an specification, but typically involve end-user interaction with an
HTML registration form. HTML registration form.
Client registration does not require a direct interaction between the Client registration does not require a direct interaction between the
client and the authorization server. When supported by the client and the authorization server. When supported by the
authorization server, registration can rely on other means for authorization server, registration can rely on other means for
establishing trust and obtaining the required client properties (e.g. establishing trust and obtaining the required client properties (e.g.
skipping to change at page 11, line 27 skipping to change at page 12, line 27
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 user-agent-based such as an installed native application or a user-agent-based
application), and incapable of secure client authentication via application), and incapable of secure client authentication via
any other mean. any other mean.
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
profiles:
web application
A web application is a private client running on a web server.
Resource owners access the client via an HTML user interface
rendered in a user-agent on the resource owner's device. The
client credentials as well as any access token issued to the
client are stored on the web server and are not exposed to or
accessible by the resource owner.
user-agent-based application
A user-agent-based application is a public client in which the
client code is downloaded from a web server and executes within a
user-agent on the resource owner's device. Protocol data and
credentials are easily accessible (and often visible) to the
resource owner. Since such applications reside within the user-
agent, they can make seamless use of the user-agent capabilities
when requesting authorization.
native application
A native application is a public client installed and executed on
the resource owner's device. Protocol data and credentials are
accessible to the resource owner. It is assumed that any client
authentication credentials included in the application can be
extracted. On the other hand, dynamically issued credentials such
access tokens or refresh tokens, can receive an acceptable level
of protection. At a minimum, these credentials are protected from
hostile servers which the application may interact with. On some
platform these credentials might be protected from other
applications residing on the same device.
2.2. Registration Requirements 2.2. Registration Requirements
When registering a client, the client developer MUST specify: When registering a client, the client developer:
o the client type as described in Section 2.1, o specifies the client type as described in Section 2.1,
o the client redirection URIs as described in Section 3.1.2, and o provides its client redirection URIs as described in
o any other information required by the authorization server (e.g. Section 3.1.2, and
application name, website, description, logo image, the acceptance o includes any other information required by the authorization
of legal terms). server (e.g. application name, website, description, logo image,
the acceptance of legal terms).
2.3. Client Identifier 2.3. 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 cannot not be used secret, it is exposed to the resource owner, and cannot be used alone
alone for client authentication. for client authentication.
2.4. Client Authentication 2.4. Client Authentication
In addition, the client and authorization server establish a client If the client type is private, the client and authorization server
authentication method suitable for the client type and security establish a client authentication method suitable for the security
requirements of the authorization server. The authorization server requirements of the authorization server. The authorization server
MAY accept any form of client authentication meeting its security MAY accept any form of client authentication meeting its security
requirements. requirements.
Private clients are typically issued (or establish) a set of client Private clients are typically issued (or establish) a set of client
credentials used for authenticating with the authorization server credentials used for authenticating with the authorization server
(e.g. password, public/private key pair). (e.g. password, public/private key pair).
The authorization server SHOULD NOT make assumptions about the client The authorization server SHOULD NOT make assumptions about the client
type or accept the type information provided without establishing type or accept the type information provided without establishing
trust with the client or its developer. The authorization server trust with the client or its developer. The authorization server MAY
MUST NOT rely on client authentication performed by public clients. establish a client authentication method with public clients.
However, the authorization server MUST NOT rely on public client
authentication for the purpose of identifying the client.
The client MUST NOT use more than one authentication method in each The client MUST NOT use more than one authentication method in each
request. request.
2.4.1. Client Password 2.4.1. Client Password
Clients in possession of a client password MAY use the HTTP Basic Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with authentication scheme as defined in [RFC2617] to authenticate with
the authorization server. The client identifier is used as the the authorization server. The client identifier is used as the
username, and the client password is used as the password. username, and the client password is used as the password.
skipping to change at page 14, line 46 skipping to change at page 16, line 32
The authorization endpoint is used by the authorization code grant The authorization endpoint is used by the authorization code grant
type and implicit grant type flows. The client informs the type and implicit grant type flows. The client informs the
authorization server of the desired grant type using the following authorization server of the desired grant type using the following
parameter: parameter:
response_type response_type
REQUIRED. The value MUST be one of "code" for requesting an REQUIRED. The value MUST be one of "code" for requesting an
authorization code as described by Section 4.1.1, "token" for authorization code as described by Section 4.1.1, "token" for
requesting an access token (implicit grant) as described by requesting an access token (implicit grant) as described by
Section 4.2.1, or a registered extension value as described by Section 4.2.1, or a registered extension value as described by
Section 8.4. Section 8.4. If the response type contains one or more space
characters (%x20), it is interpreted as a space-delimited list
of values, where the order of values does not matter (e.g. "a
b" is the same as "b a").
If an authorization request is missing the "response_type" parameter, If an authorization request is missing the "response_type" parameter,
the authorization server SHOULD return an error response as described the authorization server SHOULD return an error response as described
in Section 4.1.2.1. in Section 4.1.2.1.
3.1.2. Redirection URI 3.1.2. Redirection Endpoint
[[ Pending Consensus ]]
After completing its interaction with the resource owner, the After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to authorization server directs the resource owner's user-agent back to
the client. The authorization server redirects the user-agent to the the client. The authorization server redirects the user-agent to the
client's redirection URI previously established with the client's redirection endpoint previously established with the
authorization server during the client registration process. authorization server during the client registration process or when
initiating the authorization request.
The redirection URI MUST be an absolute URI as defined by [RFC3986] The redirection endpoint URI MUST be an absolute URI as defined by
section 4.3, MAY include a query component which MUST be retained by [RFC3986] section 4.3, MAY include a query component which MUST be
the authorization server when adding additional query parameters, and retained by the authorization server when adding additional query
MUST NOT include a fragment component. parameters, and MUST NOT include a fragment component.
3.1.2.1. Endpoint Confidentiality 3.1.2.1. Endpoint Confidentiality
If a redirection request will result in the transmission of an If a redirection request will result in the transmission of an
authorization code or access token over an open network (between the authorization code or access token over an open network (between the
resource owner's user-agent and the client), the client SHOULD resource owner's user-agent and the client), the client SHOULD
require the use of a transport-layer security mechanism. require the use of a transport-layer security mechanism.
Lack of transport-layer security can have a severe impact on the Lack of transport-layer security can have a severe impact on the
security of the client and the protected resources it is authorized security of the client and the protected resources it is authorized
skipping to change at page 17, line 36 skipping to change at page 19, line 20
The client MUST use the HTTP "POST" method when making access token The client MUST use the HTTP "POST" method when making access token
requests. requests.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server 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
[[ Pending Consensus ]]
Private clients, clients issued client credentials, or clients Private clients, clients issued client credentials, or clients
assigned other authentication requirements, MUST authenticate with assigned other authentication requirements, MUST authenticate with
the authorization server as described in Section 2.4 when making the authorization server as described in Section 2.4 when making
requests to the token endpoint. Client authentication is used for: requests 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 URI 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 Recovery from a compromised client by disabling the client or o Recovery from a compromised client by disabling the client or
changing its credentials, by preventing an attacker from abusing changing its credentials, by 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
refresh tokens. refresh tokens.
o Implementing authentication management best practices which o Implementing authentication management best practices which
require periodic credentials rotation. Rotation of an entire set require periodic credentials rotation. Rotation of an entire set
of refresh tokens can be challenging, while rotation of a single of refresh tokens can be challenging, while rotation of a single
set of client credentials is significantly easier. In addition, set of client credentials is significantly easier.
this specification does not provide a mechanism for refresh token
rotation.
The security ramifications of allowing unauthenticated access by The security ramifications of allowing unauthenticated access by
public clients to the token endpoint MUST be considered, as well as public clients to the token endpoint MUST be considered, as well as
the issuance of refresh tokens to public clients, their scope, and the issuance of refresh tokens to public clients, their scope, and
lifetime. lifetime.
4. Obtaining Authorization 4. Obtaining Authorization
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner. The authorization is expressed in the form of an resource owner. The authorization is expressed in the form of an
skipping to change at page 40, line 31 skipping to change at page 41, line 31
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 private clients or for any o require client authentication for private clients or for any
client issued client credentials (or with other authentication client issued client credentials (or with other authentication
requirements), 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,
o validate the refresh token, and o validate the refresh token, and
o verify that the resource owner's authorization is still valid.
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
refresh token after issuing a new refresh token to the client. If a refresh token after issuing a new refresh token to the client. If a
skipping to change at page 43, line 15 skipping to change at page 44, line 15
8.3. Defining New Authorization Grant Types 8.3. Defining New Authorization Grant Types
New authorization grant types can be defined by assigning them a New authorization grant types can be defined by assigning them a
unique absolute URI for use with the "grant_type" parameter. If the unique absolute URI for use with the "grant_type" parameter. If the
extension grant type requires additional token endpoint parameters, extension grant type requires additional token endpoint parameters,
they MUST be registered in the OAuth parameters registry as described they MUST be registered in the OAuth parameters registry as described
by Section 11.2. by Section 11.2.
8.4. Defining New Authorization Endpoint Response Types 8.4. Defining New Authorization Endpoint Response Types
[[ Pending consensus ]]
New response types for use with the authorization endpoint are New response types for use with the authorization endpoint are
defined and registered in the authorization endpoint response type defined and registered in the authorization endpoint response type
registry following the procedure in Section 11.3. Response type registry following the procedure in Section 11.3. Response type
names MUST conform to the response-type ABNF. names MUST conform to the response-type ABNF.
response-type = response-name *( "+" response-name ) response-type = response-name *( SP response-name )
response-name = 1*response-char response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA response-char = "_" / DIGIT / ALPHA
The "+" character is reserved for defining composite response types If a response type contains one of more space characters (%x20), it
made up of two or more existing registered response types. Only one is compared as a space-delimited list of values in which the order of
response type of each combination may be registered and used for values does not matter. Only one order of values can be registered,
making requests. Composite response types are treated and compared which covers all other arrangements of the same set of values.
in the same as manner as non-composite response types. The "+"
notation is meant only to improve human readability and is not used
for machine parsing.
For example, an extension can define and register the "token+code" For example, the response type "token code" is left undefined by this
response type. However, once registered, the same combination cannot specification. However, an extension can define and register the
be registered as "code+token", or used to make an authorization "token code" response type. Once registered, the same combination
request. cannot be registered as "code token", but both values can be used to
denote the same response type.
8.5. Defining Additional Error Codes 8.5. Defining Additional Error Codes
In cases where protocol extensions (i.e. access token types, In cases where protocol extensions (i.e. access token types,
extension parameters, or extension grant types) require additional extension parameters, or extension grant types) require additional
error codes to be used with the authorization code grant error error codes to be used with the authorization code grant error
response (Section 4.1.2.1), the implicit grant error response response (Section 4.1.2.1), the implicit grant error response
(Section 4.2.2.1), or the token error response (Section 5.2), such (Section 4.2.2.1), or the token error response (Section 5.2), such
error codes MAY be defined. error codes MAY be defined.
skipping to change at page 45, line 28 skipping to change at page 46, line 27
o Native applications that use the authorization code grant type o Native applications that use the authorization code grant type
SHOULD do so without using client credentials, due to the native SHOULD do so without using client credentials, due to the native
application's inability to keep credentials confidential. application's inability to keep credentials confidential.
o When using the implicit grant type flow a refresh token is not o When using the implicit grant type flow a refresh token is not
returned. returned.
10. Security Considerations 10. Security Considerations
As a flexible and extensible framework, OAuth's security As a flexible and extensible framework, OAuth's security
considerations depend on many factors. The following sections considerations depend on many factors. The following sections
provide implementers with security guidelines focused on three common provide implementers with security guidelines focused on the three
client types: client profiles described in Section 2.1: web application, user-
agent-based application, and native application.
Web Application
A web application is a client running on a web server. Resource
owners access the client via an HTML user interface rendered in a
user-agent on the resource-owner's device. The client credentials
as well as any access token issued to the client are stored on the
web server and are not exposed to or accessible by the resource
owner.
User-Agent-based Application
A user-agent-based application is a client in which the client
code is downloaded from a web server and executes within a user-
agent on the resource owner's device. Protocol data and
credentials are easily accessible (and often visible) to the
resource owner. Since such applications reside within the user-
agent, they can make seamless use of the user-agent capabilities
when requesting authorization.
Native Application
A native application is a client installed and executed on the
resource owner's device. Protocol data and credentials are
accessible to the resource owner. It is assumed that any client
authentication credentials included in the application can be
extracted, and furthermore that rotation of the client
authentication credentials is impractical. On the other hand,
dynamically issued credentials such access tokens or refresh
tokens, can receive an acceptable level of protection. At a
minimum, these credentials are protected from hostile servers
which the application may interact with. On some platform these
credentials might be protected from other applications residing on
the same device.
A comprehensive OAuth security model and analysis, as well as A comprehensive OAuth security model and analysis, as well as
background for the protocol design is provided by background for the protocol design is provided by
[I-D.lodderstedt-oauth-security]. [I-D.ietf-oauth-v2-threatmodel].
10.1. Client Authentication 10.1. Client Authentication
The authorization server establishes client credentials with web The authorization server establishes client credentials with web
application clients for the purpose of client authentication. The application clients for the purpose of client authentication. The
authorization server is encouraged to consider stronger client authorization server is encouraged to consider stronger client
authentication means than a client password. Web application clients authentication means than a client password. Web application clients
MUST ensure confidentiality of client passwords and other client MUST ensure confidentiality of client passwords and other client
credentials. credentials.
The authorization server MUST NOT issue client passwords or other The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based client credentials to native application or user-agent-based
application clients for the purpose of client authentication. The application clients for the purpose of client authentication. The
authorization server MAY issue a client password or other credentials authorization server MAY issue a client password or other credentials
for a specific installation of a native application client on a for a specific installation of a native application client on a
specific device. specific device.
When client authentication is not possible, the authorization server
SHOULD employ other means to validate the client's identity. For
example, by requiring the registration of the client redirection URI
or enlisting the resource owner to confirm identity. The
authorization server must consider the security implications of
interacting with unauthenticated clients and take measures to limit
the potential exposure of other credentials (e.g. refresh tokens)
issued to such clients.
10.2. Client Impersonation 10.2. Client Impersonation
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 is client credentials confidential. unable to, keep is 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 nature, the authorization server MUST require the due to the client 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,
skipping to change at page 47, line 8 skipping to change at page 47, line 35
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 the request. the current client, and authorize 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
ensure the repeated request comes from an authentic client and not an ensure the repeated request comes from the original client and not an
impersonator. impersonator.
10.3. Access Tokens 10.3. Access Tokens
Access token (as well as any type-specific attributes) MUST be kept Access token (as well as any access token type-specific attributes)
confidential in transit and storage, and only shared among the MUST be kept confidential in transit and storage, and only shared
authorization server, the resource servers the access token is valid among the authorization server, the resource servers the access token
for, and the client to whom the access token is issued. is valid for, and the client to whom the access token is issued.
When using the implicit grant type, the access token is transmitted When using the implicit grant type, the access token is transmitted
in the URI fragment, which can expose it to unauthorized parties. in the URI fragment, which can expose it to unauthorized parties.
The authorization server MUST ensure that access tokens cannot be The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens. generated, modified, or guessed to produce valid access tokens.
The client SHOULD request access tokens with the minimal scope and The client SHOULD request access tokens with the minimal scope and
lifetime necessary. The authorization server SHOULD take the client lifetime necessary. The authorization server SHOULD take the client
identity into account when choosing how to honor the requested scope identity into account when choosing how to honor the requested scope
skipping to change at page 47, line 45 skipping to change at page 48, line 24
Refresh tokens MUST be kept confidential in transit and storage, and Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was the binding between a refresh token and the client to whom it was
issued. issued.
The authorization server MUST verify the binding between the refresh The authorization server MUST verify the binding between the refresh
token and client identity whenever the client identity can be token and client identity whenever the client identity can be
authenticated. When client authentication is not possible, the authenticated. When client authentication is not possible, the
authorization server SHOULD deploy other means to detect refresh authorization server SHOULD deploy other means to detect refresh
token abuse [[ add example ]]. token abuse.
For example, the authorization server could employ refresh tokens
rotation in which a new refresh token is issued with every access
token refresh response. The previous refresh token is invalidated
but retained by the authorization server. If a refresh token is
compromised and subsequently used by both the attacker and the
legitimate client, one of them will present an invalidated refresh
token which will inform the authorization server of the breach.
The authorization server MUST ensure that refresh tokens cannot be The authorization server MUST ensure that refresh tokens cannot be
generated, modified, or guessed to produce valid refresh tokens. generated, modified, or guessed to produce valid refresh tokens.
10.5. Authorization Codes 10.5. Authorization Codes
The transmission of authorization codes SHOULD be made over a secure The transmission of authorization codes SHOULD be made over a secure
channel, and the client SHOULD implement TLS for use with its channel, and the client SHOULD 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
skipping to change at page 48, line 34 skipping to change at page 49, line 18
authorization code for an access token, the authorization server authorization code for an access token, the authorization server
SHOULD attempt to revoke all access tokens already granted based on SHOULD attempt to revoke all access tokens already granted based on
the compromised authorization code. the compromised authorization code.
If the client can be authenticated, the authorization servers MUST If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was authenticate the client and ensure that the authorization code was
issued to the same client. issued to the same client.
10.6. Authorization Code Leakage 10.6. Authorization Code Leakage
Session fixation attacks leverage the authorization code grant type, An attacker can leverage the authorization code grant type by
by tricking a resource owner to authorize access to a legitimate tricking a resource owner to authorize access to a legitimate client,
client, but using a client account under the control of the attacker. but using a client account under the control of the attacker. The
The only difference between a valid request and the attack request is only difference between a valid request and the attack request is in
in how the victim reached the authorization server to grant access. how the victim reached the authorization server to grant access.
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 familiar client.
The attacker then uses the victim's authorization to gain access to The attacker then uses the victim's authorization to gain access to
the information authorized by the victim (via the client). the information authorized by the victim (via the client).
In order to prevent such an attack, authorization servers MUST ensure In order to prevent such an attack, authorization servers MUST ensure
that the redirection URI used to obtain the authorization code, is that the redirection URI used to obtain the authorization code, is
the same as the redirection URI provided when exchanging the the same as 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
skipping to change at page 51, line 30 skipping to change at page 52, line 15
To prevent clickjacking (and phishing attacks), native applications To prevent clickjacking (and phishing attacks), native applications
SHOULD use external browsers instead of embedding browsers in an SHOULD use external browsers instead of embedding browsers in an
iframe when requesting end-user authorization. For newer browsers, iframe when requesting end-user authorization. For newer browsers,
avoidance of iframes can be enforced by the authorization server avoidance of iframes can be enforced by the authorization server
using the "x-frame-options" header [[ Add reference ]]. This header using the "x-frame-options" header [[ Add reference ]]. This header
can have two values, "deny" and "sameorigin", which will block any can 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
A code injection attack occurs when an input or otherwise external
variable is used by an application in which that input can cause
modification of the application logic when used unsanitized. This
may allow an attacker to gain access to the application device or its
data, cause denial of service, or a wide range of malicious side-
effects.
The Authorization server and client MUST validate and sanitize any
value received, and in particular, the value of the "state" and
"redirect_uri" parameters.
11. IANA Considerations 11. IANA Considerations
11.1. The OAuth Access Token Type Registry 11.1. The OAuth Access Token Type Registry
This specification establishes the OAuth access token type registry. This specification establishes the OAuth access token type registry.
Access token types are registered on the advice of one or more Access token types are registered on the advice of one or more
Designated Experts (appointed by the IESG or their delegate), with a Designated Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]). However, Specification Required (using terminology from [RFC5226]). However,
to allow for the allocation of values prior to publication, the to allow for the allocation of values prior to publication, the
skipping to change at page 58, line 48 skipping to change at page 59, line 43
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, Scott Cantor, Blaine Michael Adams, Andrew Arnott, Dirk Balfanz, Aiden Bell, Scott Cantor,
Cook, Brian Campbell, Brian Eaton, Leah Culver, Bill de hOra, Brian Marcos Caceres, Blaine Cook, Brian Campbell, Brian Eaton, Leah
Eaton, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan Culver, Bill de hOra, Brian Eaton, Brian Ellin, Igor Faynberg, George
Gilbert, Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, Brent Goldman,
Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, John Kristoffer Gronowski, Justin Hart, Dick Hardt, Craig Heath, Phil
Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen
Torsten Lodderstedt, Hui-Lan Lu, Paul Madsen, Alastair Mair, Eve Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Paul
Maler, James Manger, Mark McGloin, Laurence Miao, Chuck Mortimore, Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin,
Anthony Nadalin, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter
Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah,
Justin Smith, Jeremy Suriel, Christian Stuebner, Paul Tarjan, Allen Luke Shepard, Vlad Skvortsov, Justin Smith, Jeremy Suriel, Christian
Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward. Stuebner, 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 60, line 33 skipping to change at page 61, line 29
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]
Jacobs, I., Hors, A., and D. Raggett, "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.
skipping to change at page 61, line 12 skipping to change at page 62, line 9
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-04 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04
(work in progress), March 2011. (work in progress), March 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.lodderstedt-oauth-security] [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",
draft-lodderstedt-oauth-security-01 (work in progress), draft-ietf-oauth-v2-threatmodel-00 (work in progress),
March 2011. July 2011.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. April 2010.
 End of changes. 44 change blocks. 
191 lines changed or deleted 219 lines changed or added

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