< draft-ietf-oauth-v2-07.txt   draft-ietf-oauth-v2-08.txt >
Network Working Group E. Hammer-Lahav, Ed. Network Working Group E. Hammer-Lahav, Ed.
Internet-Draft Yahoo! Internet-Draft Yahoo!
Intended status: Standards Track D. Recordon Intended status: Standards Track D. Recordon
Expires: December 13, 2010 Facebook Expires: December 17, 2010 Facebook
D. Hardt D. Hardt
Microsoft Microsoft
June 11, 2010 June 15, 2010
The OAuth 2.0 Protocol The OAuth 2.0 Protocol
draft-ietf-oauth-v2-07 draft-ietf-oauth-v2-08
Abstract Abstract
This specification describes the OAuth 2.0 protocol. OAuth provides This specification describes the OAuth 2.0 protocol.
a method for making authenticated HTTP requests using a token - an
string used to denote an access grant with specific scope, duration,
and other attributes. Tokens are issued to third-party clients by an
authorization server with the approval of the resource owner. OAuth
defines multiple flows for obtaining a token to support a wide range
of client types and user experience.
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 December 13, 2010. This Internet-Draft will expire on December 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 8 1.4. Client Profiles . . . . . . . . . . . . . . . . . . . . . 8
2. Client Flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4.1. Web Server . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Web Server Flow . . . . . . . . . . . . . . . . . . . . . 8 1.4.2. User-Agent . . . . . . . . . . . . . . . . . . . . . . 9
2.2. User-Agent Flow . . . . . . . . . . . . . . . . . . . . . 10 1.4.3. Native Application . . . . . . . . . . . . . . . . . . 11
2.3. Username and Password Flow . . . . . . . . . . . . . . . . 11 1.4.4. Autonomous . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Client Credentials Flow . . . . . . . . . . . . . . . . . 13 2. Client Credentials . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Assertion Flow . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Basic Client Credentials . . . . . . . . . . . . . . . . . 13
2.6. Native Application Considerations . . . . . . . . . . . . 14 3. Obtaining End-User Authorization . . . . . . . . . . . . . . . 14
3. Client Credentials . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Authorization Server Response . . . . . . . . . . . . . . 16
3.1. Client Authentication . . . . . . . . . . . . . . . . . . 15 4. Obtaining an Access Token . . . . . . . . . . . . . . . . . . 17
4. Establishing Resource Owner Authorization . . . . . . . . . . 16 4.1. Access Grant Parameters . . . . . . . . . . . . . . . . . 18
4.1. Verification Code . . . . . . . . . . . . . . . . . . . . 17 4.1.1. Authorization Code . . . . . . . . . . . . . . . . . . 18
4.1.1. End-User Authorization Endpoint . . . . . . . . . . . 17 4.1.2. Resource Owner Basic Credentials . . . . . . . . . . . 19
4.2. Resource Owner Credentials . . . . . . . . . . . . . . . . 20 4.1.3. Assertion . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4. Refresh Token . . . . . . . . . . . . . . . . . . . . 20
5. Obtaining an Access Token . . . . . . . . . . . . . . . . . . 21 4.2. Access Token Response . . . . . . . . . . . . . . . . . . 21
5.1. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Verification Code . . . . . . . . . . . . . . . . . . 22 4.3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 23
5.1.2. Resource Owner Credentials . . . . . . . . . . . . . . 22 5. Accessing a Protected Resource . . . . . . . . . . . . . . . . 23
5.1.3. Assertion . . . . . . . . . . . . . . . . . . . . . . 23 5.1. The Authorization Request Header Field . . . . . . . . . . 24
5.1.4. Refresh Token . . . . . . . . . . . . . . . . . . . . 24 5.2. URI Query Parameter . . . . . . . . . . . . . . . . . . . 25
5.1.5. Access Token Response . . . . . . . . . . . . . . . . 25 5.3. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 25
5.1.6. Error Response . . . . . . . . . . . . . . . . . . . . 26 6. The WWW-Authenticate Response Header Field . . . . . . . . . . 26
6. Accessing a Protected Resource . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1. The Authorization Request Header . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.2. URI Query Parameter . . . . . . . . . . . . . . . . . . . 28 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 29 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 27
7. Identifying a Protected Resource . . . . . . . . . . . . . . . 30 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 28
7.1. The WWW-Authenticate Response Header . . . . . . . . . . . 30 Appendix D. Document History . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix C. Document History . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
With the increasing use of distributed web services and cloud With the increasing use of distributed web services and cloud
computing, third-party applications require access to server-hosted computing, third-party applications require access to server-hosted
resources. These resources are usually protected and require resources. These resources are usually protected and require
authentication using the resource owner's credentials (typically a authentication using the resource owner's credentials (typically a
username and password). In the traditional client-server username and password). In the traditional client-server
authentication model, a client accessing a protected resource on a authentication model, a client accessing a protected resource on a
server presents the resource owner's credentials in order to server presents the resource owner's credentials in order to
authenticate and gain access. authenticate and gain access.
Resource owners should not be required to share their credentials OAuth introduces a third role to the traditional client-server
when granting third-party applications access to their protected authentication model: the resource owner. In OAuth, the client
resources. They should also have the ability to restrict access to a (which is usually not the resource owner, but is acting on its
limited subset of the resources they control, to limit access behalf) requests access to resources controlled by the resource owner
duration, or to limit access to the HTTP methods supported by these and hosted by the resource server.
In addition to removing the need for resource owners to share their
credentials, resource owners should also have the ability to restrict
access to a limited subset of the resources they control, to limit
access duration, or to limit access to the methods supported by these
resources. resources.
OAuth provides a method for making authenticated HTTP requests using Instead of using the resource owner's credentials to access protected
a token - an identifier used to denote an access grant with specific resources, clients obtain an access token (which denotes a specific
scope, duration, and other attributes. Tokens are issued to third- scope, duration, and other attributes). Tokens are issued to third-
party clients by an authorization server with the approval of the party client by an authorization server with the approval of the
resource owner. Instead of sharing their credentials with the resource owner. The client uses the access token to access the
client, resource owners grant access by authenticating directly with protected resources.
the authorization server which in turn issues a token to the client.
The client uses the token to authenticate with the resource server
and gain access.
For example, a web user (resource owner) can grant a printing service For example, a web user (resource owner) can grant a printing service
(client) access to her protected photos stored at a photo sharing (client) access to her protected photos stored at a photo sharing
service (resource server), without sharing her username and password service (resource server), without sharing her username and password
with the printing service. Instead, she authenticates directly with with the printing service. Instead, she authenticates directly with
the photo sharing service (authorization server) which issues the the photo sharing service (authorization server) which issues the
printing service delegation-specific credentials (token). printing service delegation-specific credentials (token).
This specification defines the use of OAuth over HTTP [RFC2616] (or This specification defines the use of OAuth over HTTP [RFC2616] (or
HTTP over TLS as defined by [RFC2818]). Other specifications may HTTP over TLS as defined by [RFC2818]). Other specifications may
extend it for use with other transport protocols. extend it for use with other transport protocols.
1.1. Terminology 1.1. Notational Conventions
resource server The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
An HTTP [RFC2616] server capable of accepting authenticated 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
resource requests using the OAuth protocol. document are to be interpreted as described in [RFC2119].
This document uses the Augmented Backus-Naur Form (ABNF) notation of
[I-D.ietf-httpbis-p1-messaging]. Additionally, the realm and auth-
param rules are included from [RFC2617].
Unless otherwise noted, all the protocol parameter names and values
are case sensitive.
1.2. Terminology
protected resource protected resource
An access-restricted resource which can be obtained from a An access-restricted resource which can be obtained using an
resource server using an OAuth-authenticated request. OAuth-authenticated request.
resource server
A server capable of accepting and responding to protected
resource requests.
client client
An HTTP client capable of making authenticated requests for An application obtaining authorization and making protected
protected resources using the OAuth protocol. resource requests.
resource owner resource owner
An entity capable of granting access to a protected resource. An entity capable of granting access to a protected resource.
end-user end-user
A human resource owner. A human resource owner.
token token
A string representing an access grant issued to the client. A string representing an access authorization issued to the
The string is usually opaque to the client and can self-contain client. The string is usually opaque to the client and can
the authorization information in a verifiable manner (i.e. self-contain the authorization information in a verifiable
signed), or denotes an identifier used to retrieve the manner (i.e. signed), or denotes an identifier used to retrieve
authorization information. the information. Tokens represent a specific scope, duration,
and other authorization attributes granted by the resource
owner and enforced by the resource server and authorization
servers.
access token access token
A token used by the client to make authenticated requests on A token used by the client to make authenticated requests
behalf of the resource owner. Access tokens represent a on behalf of the resource owner.
specific scope, duration, and other access attributes granted
by the resource owner and enforced by the resource and
authorization servers.
refresh token refresh token
A token used by the client to replace an expired access token A token used by the client to obtain a new access token
with a new access token without having to involve the resource (in addition or as a replacement for an expired access
owner. A refresh token is used when the access token is valid token), without having to involve the resource owner.
for a shorter time period than the duration of the access grant
granted by the resource owner. authorization code A short-lived token representing the access
grant provided by the end-user. The authorization code
is used to obtain an access token and a refresh token.
authorization server authorization server
An HTTP server capable of issuing tokens after successfully A server capable of issuing tokens after successfully
authenticating the resource owner and obtaining authorization. authenticating the resource owner and obtaining authorization.
The authorization server may be the same server as the resource The authorization server may be the same server as the resource
server, or a separate entity. server, or a separate entity.
end-user authorization endpoint end-user authorization endpoint
The authorization server's HTTP endpoint capable of The authorization server's HTTP endpoint capable of
authenticating the end-user and obtaining authorization. authenticating the end-user and obtaining authorization. The
end-user authorization endpoint is described in Section 3.
token endpoint token endpoint
The authorization server's HTTP endpoint capable of issuing The authorization server's HTTP endpoint capable of issuing
tokens and refreshing expired tokens. tokens and refreshing expired tokens. The token endpoint is
described in Section 4.
client identifier client identifier
An unique identifier issued to the client to identify itself to An unique identifier issued to the client to identify itself to
the authorization server. Client identifiers may have a the authorization server. Client identifiers may have a
matching secret. matching secret. The client identifier is described in
Section 2.
1.2. Overview 1.3. Overview
Clients interact with a protected resource, first by requesting OAuth provides a method for clients to access a protected resource on
access (which is granted in the form of an access token) from the behalf of a resource owner. Before a client can access a protected
authorization server, and then by authenticating with the resource resource, it must first obtain authorization from the resource owner,
server by presenting the access token. Figure 1 demonstrates the then exchange that access grant for an access token (representing the
flow between the client and authorization server (A, B), and the flow grant's scope, duration, and other attributes). The client accesses
between the client and resource server (C, D), when the client is the protected resource by presenting the access token to the resource
acting autonomously (the client is also the resource owner). server.
+--------+ +---------------+ +--------+ +---------------+
| |--(A)------ Credentials --------->| Authorization | | |--(A)-- Authorization Request --->| Resource |
| | | Server | | | | Owner |
| |<-(B)------ Access Token ---------| | | |<-(B)------ Access Grant ---------| |
| | +---------------+
| |
| | Client Credentials & +---------------+
| |--(C)------ Access Grant -------->| Authorization |
| Client | | Server |
| |<-(D)------ Access Token ---------| |
| | (w/ Optional Refresh Token) +---------------+ | | (w/ Optional Refresh Token) +---------------+
| Client | | |
| | HTTP Request +---------------+
| |--(C)--- with Access Token ------>| Resource |
| | | Server |
| |<-(D)------ HTTP Response --------| |
+--------+ +---------------+
Figure 1: Generic Client-Server Flow
Access token strings can use any internal structure agreed upon
between the authorization server and the resource server, but their
structure is opaque to the client. Since the access token provides
the client access to the protected resource for the life of the
access token (or until revoked), the authorization server should
issue access tokens which expire within an appropriate time, usually
much shorter than the duration of the access grant.
When an access token expires, the client can request a new access
token from the authorization server by presenting its credentials
again (Figure 1), or by using the refresh token (if issued with the
access token) as shown in Figure 2. Once an expired access token has
been replaced with a new access token (A, B), the client uses the new
access token as before (C, D).
+--------+ +---------------+
| |--(A)------ Refresh Token ------->| Authorization |
| | | Server |
| |<-(B)------ Access Token ---------| |
| | +---------------+ | | +---------------+
| Client | | |--(E)------ Access Token -------->| Resource |
| | HTTP Request +---------------+
| |--(C)--- with Access Token ------>| Resource |
| | | Server | | | | Server |
| |<-(D)----- HTTP Response ---------| | | |<-(F)---- Protected Resource -----| |
+--------+ +---------------+ +--------+ +---------------+
Figure 2: Refreshing an Access Token Figure 1: Abstract Protocol Flow
This specification defines a number of authorization flows to support The abstract flow illustrated in Figure 1 includes the following
different client types and scenarios. These authorization flows can steps:
be separated into three groups: user delegation flows, direct
credentials flows, and autonomous flows.
Additional authorization flows may be defined by other specifications (A) The client requests authorization from the resource owner. The
to cover different scenarios and client types. client should not interact directly with the resource owner
(since that would exposing the resource owner's credentials to
the client), but instead requests authorization via an
authorization server or other entities. For example, the client
directs the resource owner to the authorization server which in
turn issues it an access grant. When cannot be avoided, the
client interacts directly with the end-user, asking for the end-
user's username and password.
User delegation flows are used to grant client access to protected (B) The client is issued an access grant which represents the
resources by the end-user without sharing the end-user credentials authorization provided by the resource owner. The access grant
(e.g. a username and password) with the client. Instead, the end- can be expressed as:
user authenticates directly with the authorization server, and grants
client access to its protected resources. The user delegation flows
defined by this specifications are:
o Web Server Flow - This flow is optimized for clients that are part * Authorization code - an access grant obtained via an
of a web server application, accessible via HTTP requests. This authorization server. The process used to obtain an
flow is described in Section 2.1. authorization code is described in Section 3.
o User-Agent Flow - This flow is designed for clients running inside * Assertion - an access grant obtained from entities using a
a user-agent (typically a web browser). This flow is described in different trust framework. Assertions enable the client to
Section 2.2. utilize existing trust relationships to obtain an access
token. They provide a bridge between OAuth and other trust
frameworks. The access grant represented by an assertion
depends on the assertion type, its content, and how it was
issued, which are beyond the scope of this specification.
Direct credentials flows enable clients to obtain an access token * Basic end-user credentials - obtained when interacting
with a single request using the client credentials or end-user directly with an end-user. Resource owner credentials should
credentials without seeking additional resource owner authorization. only be used when there is a high degree of trust between the
The direct credentials flows defined by this specification are: resource owner the client (e.g. its computer operating system
or a highly privileged application). However, unlike the
HTTP Basic authentication scheme defined in [RFC2617], the
end-user's credentials are used in a single request and are
exchanged for an access token and refresh token which
eliminates the client need to store them for future use.
o Username and Password Flow - This flow is used in cases where the (C) The client requests an access token by authenticating with the
end-user trusts the client to handle its credentials but it is authorization server, and presenting the access grant. The
still undesirable for the client to store the end-user's username token request is described in Section 4.
and password. This flow is only suitable when there is a high
degree of trust between the end-user and the client. This flow is
described in Section 2.3.
o Client Credentials Flow - The client uses its credentials to (D) The authorization server validated the client credentials and
obtain an access token. This flow is described in Section 2.4. the access grant, and issues an access token with an optional
refresh token. Access token usually have a shorter lifetime
than the access grant. Refresh tokens usually have a lifetime
equal to the duration of the access grant. When an access token
expires, the refresh token is used to obtain a new access token
without having to request another access grant from the resource
owner (in which case, the refresh token acts as an access
grant).
Autonomous flows enable clients to utilize existing trust (E) The client makes a protect resource request to the resource
relationships or different authorization constructs to obtain an server, and presents the access token in order to gain access.
access token. They provide a bridge between OAuth and other trust Accessing a protected resource is described in Section 5.
frameworks. The autonomous authorization flow defined by this
specifications is:
o Assertion Flow - The client presents an assertion such as a SAML (F) The resource server validates the access token, and if valid,
[OASIS.saml-core-2.0-os] assertion to the authorization server in serves the request.
exchange for an access token. This flow is described in
Section 2.5. When the client is acting on behalf of itself (the client is also the
resource owner), the client skips steps (A) and (B), and does not
include an access grant in step (C). When the client uses the user-
agent profile (described in Section 1.4.2), the authorization request
(A) results in an access token (D), skipping steps (B) and (C).
The sizes of tokens and other values received from the authorization The sizes of tokens and other values received from the authorization
server, are left undefined by this specification. Clients should server, are left undefined by this specification. Clients should
avoid making assumptions about value sizes. Servers should document avoid making assumptions about value sizes. Servers should document
the expected size of any value they issue. the expected size of any value they issue.
1.3. Example 1.4. Client Profiles
[[ Todo ]]
1.4. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119].
This document uses the Augmented Backus-Naur Form (ABNF) notation of
[I-D.ietf-httpbis-p1-messaging]. Additionally, the realm and auth-
param rules are included from [RFC2617].
Unless otherwise noted, all the protocol parameter names and values
are case sensitive.
2. Client Flows OAuth supports a wide range of client types by providing a rich and
extensible framework for establishing authorization and exchaning it
for an access token. The methods detailed in this specification were
designed to accomodate four client types: web servers, user-agents,
native applications, and autonomous clients. Additional
authorization flows and client profiles may be defined by other
specifications to cover additional scenarios and client types.
2.1. Web Server Flow 1.4.1. Web Server
The web server flow is a user delegation flow suitable for clients The web server profile is suitable for clients capable of interacting
capable of interacting with the end-user's user-agent (typically a with the end-user's user-agent (typically a web browser) and capable
web browser) and capable of receiving incoming requests from the of receiving incoming requests from the authorization server (capable
authorization server (capable of acting as an HTTP server). of acting as an HTTP server).
+----------+ Client Identifier +---------------+ +----------+ Client Identifier +---------------+
| -+----(A)-- & Redirect URI ------->| | | -+----(A)--- & Redirect URI ------>| |
| End-user | | Authorization | | End-user | | Authorization |
| at |<---(B)-- User authenticates --->| Server | | at |<---(B)-- User authenticates --->| Server |
| Browser | | | | Browser | | |
| -+----(C)-- Verification Code ----<| | | -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+ +-|----|---+ +---------------+
| | ^ v | | ^ v
(A) (C) | | (A) (C) | |
| | | | | | | |
^ v | | ^ v | |
+---------+ | | +---------+ | |
| |>---(D)-- Client Credentials, --------' | | |>---(D)-- Client Credentials, --------' |
| Web | Verification Code, | | Web | Authorization Code, |
| Client | & Redirect URI | | Client | & Redirect URI |
| | | | | |
| |<---(E)------- Access Token -----------------' | |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token) +---------+ (w/ Optional Refresh Token)
Figure 3: Web Server Flow Figure 2: Web Server Flow
The web server flow illustrated in Figure 3 includes the following The web server flow illustrated in Figure 2 includes the following
steps: steps:
(A) The web client initiates the flow by redirecting the end-user's (A) The web client initiates the flow by redirecting the end-user's
user-agent to the end-user authorization endpoint as described user-agent to the end-user authorization endpoint as described
in Section 4.1.1 using client type "web_server". The client in Section 3 using client type "web_server". The client
includes its client identifier, requested scope, local state, includes its client identifier, requested scope, local state,
and a redirect URI to which the authorization server will send and a redirect URI to which the authorization server will send
the end-user back once authorization is granted (or denied). the end-user back once access is granted (or denied).
(B) The authorization server authenticates the end-user (via the (B) The authorization server authenticates the end-user (via the
user-agent) and establishes whether the end-user grants or user-agent) and establishes whether the end-user grants or
denies the client's access request. denies the client's access request.
(C) Assuming the end-user granted access, the authorization server (C) Assuming the end-user granted access, the authorization server
redirects the user-agent back to the client to the redirection redirects the user-agent back to the client to the redirection
URI provided earlier. The authorization includes a verification URI provided earlier. The authorization includes an
code for the client to use to obtain an access token. authorization code for the client to use to obtain an access
token.
(D) The client requests an access token from the authorization (D) The client requests an access token from the authorization
server by authenticating and including the verification code server by authenticating and including the authorization code
received in the previous step as described in Section 5.1. received in the previous step as described in Section 4.
(E) The authorization server validates the client credentials and (E) The authorization server validates the client credentials and
the verification code and responds back with the access token. the authorization code and responds back with the access token.
2.2. User-Agent Flow 1.4.2. User-Agent
The user-agent flow is a user delegation flow suitable for client The user-agent profile is suitable for client applications residing
applications residing in a user-agent, typically implemented in a in a user-agent, typically implemented in a browser using a scripting
browser using a scripting language such as JavaScript. These clients language such as JavaScript. These clients cannot keep client
cannot keep client secrets confidential and the authentication of the secrets confidential and the authentication of the client is based on
client is based on the user-agent's same-origin policy. the user-agent's same-origin policy.
Unlike other flows in which the client makes separate authorization Unlike other profiles in which the client makes a separate end-user
and access token requests, the client received the access token as a authorization request and an access token requests, the client
result of the authorization request in the form of an HTTP receives the access token as a result of the end-user authorization
redirection. The client requests the authorization server to request in the form of an HTTP redirection. The client requests the
redirect the user-agent to another web server or local resource authorization server to redirect the user-agent to another web server
accessible to the browser which is capable of extracting the access or local resource accessible to the user-agent which is capable of
token from the response and passing it to the client. extracting the access token from the response and passing it to the
client.
This user-agent flow does not utilize the client secret since the This user-agent profile does not utilize the client secret since the
client executables reside on the end-user's computer or device which client executables reside on the end-user's computer or device which
makes the client secret accessible and exploitable. Because the makes the client secret accessible and exploitable. Because the
access token is encoded into the redirection URI, it may be exposed access token is encoded into the redirection URI, it may be exposed
to the end-user and other applications residing on the computer or to the end-user and other applications residing on the computer or
device. device.
+----------+ Client Identifier +----------------+ +----------+ Client Identifier +----------------+
| |>---(A)-- & Redirection URI --->| | | |>---(A)-- & Redirection URI --->| |
| | | | | | | |
End <--+ - - - +----(B)-- User authenticates -->| Authorization | End <--+ - - - +----(B)-- User authenticates -->| Authorization |
User | | | Server | User | | | Server |
| |<---(C)-- Redirect URI --------<| | | |<---(C)--- Redirect URI -------<| |
| Client | with Access Token | | | Client | with Access Token | |
| in | (w/ Optional Refresh Token) +----------------+ | in | (w/ Optional Authorization +----------------+
| Browser | in Fragment | Browser | Code) in Fragment
| | +----------------+ | | +----------------+
| |>---(D)-- Redirect URI -------->| | | |>---(D)--- Redirect URI ------->| |
| | without Fragment | Web Server | | | without Fragment | Web Server |
| | | with Client | | | | with Client |
| (F) |<---(E)-- Web Page with -------<| Resource | | (F) |<---(E)--- Web Page with ------<| Resource |
| Access | Script | | | Access | Script | |
| Token | +----------------+ | Token | +----------------+
+----------+ +----------+
Figure 4: User-Agent Flow
The user-agent flow illustrated in Figure 4 includes the following Figure 3: User-Agent Flow
The user-agent flow illustrated in Figure 3 includes the following
steps: steps:
(A) The client sends the user-agent to the end-user authorization (A) The client sends the user-agent to the end-user authorization
endpoint as described in Section 4.1.1 using client type endpoint as described in Section 3 using client type
"user-agent". The client includes its client identifier, "user-agent". The client includes its client identifier,
requested scope, local state, and a redirect URI to which the requested scope, local state, and a redirect URI to which the
authorization server will send the end-user back once authorization server will send the end-user back once
authorization is granted (or denied). authorization is granted (or denied).
(B) The authorization server authenticates the end-user (via the (B) The authorization server authenticates the end-user (via the
user-agent) and establishes whether the end-user grants or user-agent) and establishes whether the end-user grants or
denies the client's access request. denies the client's access request.
(C) Assuming the end-user granted access, the authorization server (C) If the end-user granted access, the authorization server
redirects the user-agent to the redirection URI provided redirects the user-agent to the redirection URI provided
earlier. The redirection URI includes the access token (and an earlier. The redirection URI includes the access token (and an
optional verification code) in the URI fragment. optional authorization code) in the URI fragment.
(D) The user-agent follows the redirection instructions by making an (D) The user-agent follows the redirection instructions by making a
HTTP "GET" request to the web server which does not include the request to the web server which does not include the fragment.
fragment. The user-agent retains the fragment information The user-agent retains the fragment information locally.
locally. The user-agent MUST NOT include the fragment component
with the request.
(E) The web server returns a web page (typically an HTML page with (E) The web server returns a web page (typically an HTML page with
an embedded script) capable of accessing the full redirection an embedded script) capable of accessing the full redirection
URI including the fragment retained by the user-agent, and URI including the fragment retained by the user-agent, and
extracting the access token (and other parameters) contained in extracting the access token (and other parameters) contained in
the fragment. the fragment.
(F) The user-agent executes the script provided by the web server (F) The user-agent executes the script provided by the web server
which extracts the access token and passes it to the client. If which extracts the access token and passes it to the client. If
a verification code was issued, the client can pass it to a web an authorization code was issued, the client can pass it to a
server component to obtain another access token for additional web server component to obtain another access token for
server-based protected resources interaction. additional server-based protected resources interaction.
2.3. Username and Password Flow
The username and password flow is suitable for clients capable of
asking end-users for their usernames and passwords. It is also used
to migrate existing clients using direct authentication schemes such
as HTTP Basic or Digest authentication to OAuth by converting the
end-user credentials stored with tokens.
However, unlike the HTTP Basic authentication scheme defined in
[RFC2617], the end-user's credentials are used in a single request
and are exchanged for an access token and refresh token which
eliminates the client need to store them for future use.
The methods through which the client prompts end users for their
usernames and passwords is beyond the scope of this specification.
The client MUST discard the usernames and passwords once an access
token has been obtained.
This flow is suitable in cases where the end-user already has a trust
relationship with the client, such as its computer operating system
or highly privileged applications. Authorization servers should take
special care when enabling the username and password flow, and only
when other delegation flows are not viable.
End-user
v
:
(A)
:
v
+--------+ +---------------+
| | Client Credentials | |
| |>--(B)--- & User Credentials ---->| Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+--------+ +---------------+
Figure 5: Username and Password Flow
The username and password flow illustrated in Figure 5 includes the
following steps:
(A) The end-user provides the client with its username and password.
(B) The client requests an access token from the authorization
server by authenticating and including the end-user's username
and password, and desired scope as described in Section 5.1.
(C) The authorization server validates the end-user credentials and
the client credentials and issues an access token.
2.4. Client Credentials Flow
The client credentials flow is used when the client acts on behalf of
itself (the client is the resource owner), or when the client
credentials are used to obtain an access token representing a
previously established access authorization. The client secret is
assumed to be high-entropy since it is not designed to be memorized
by an end-user.
+--------+ +---------------+
| | | |
| |>--(A)--- Client Credentials ---->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+--------+ +---------------+
Figure 6: Client Credentials Flow
The client credential flow illustrated in Figure 6 includes the
following steps:
(A) The client requests an access token from the authorization
server by authenticating and including the desired scope as
described in Section 5.1. No additional authorization grant
information is needed.
(B) The authorization server validates the client credentials and
issues an access token.
2.5. Assertion Flow
The assertion flow is used when a client wishes to exchange an
existing security token or assertion for an access token. This flow
is suitable when the client is the resource owner or is acting on
behalf of the resource owner (based on the content of the assertion
used).
The assertion flow requires the client to obtain a assertion (such as
a SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer
or to self-issue an assertion prior to initiating the flow. The
assertion format, the process by which the assertion is obtained, and
the method of validating the assertion are defined by the assertion
issuer and the authorization server, and are beyond the scope of this
specification.
+--------+ +---------------+
| | | |
| |>--(A)------ Assertion ---------->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+--------+ +---------------+
Figure 7: Assertion Flow
The assertion flow illustrated in Figure 7 includes the following
steps:
(A) The client requests an access token from the authorization
server by authenticating and including the assertion, assertion
type, and desired scope as described in Section 5.1.
(B) The authorization server validates the assertion and issues an
access token.
2.6. Native Application Considerations 1.4.3. Native Application
Native application are clients running as native code on the end- Native application are clients running as native code on the end-
user's computer or device (i.e. executing outside a browser or as a user's computer or device (i.e. executing outside a user-agent or as
desktop program). These clients are often capable of interacting a desktop program). These clients are often capable of interacting
with (or embedding) the end-user's user-agent but are incapable of with (or embedding) the end-user's user-agent but are incapable of
receiving callback requests from the server (incapable of acting as receiving callback requests from the server (incapable of acting as
an HTTP server). an HTTP server).
Native application clients can utilize many of the flows defined in Native application clients can be implemented in different ways based
this specification with little or no changes. For example: on their requirements and desired end-user experience. Native
application clients can:
o Launch an external user-agent and have it redirect back to the
client using a custom URI scheme. This works with the web server
flow and user-agent flow.
o Launch an external user-agent and poll for changes to the window o Utilize the end-user authorization endpoint as described in
title. This works with the web server flow with a server-hosted Section 3 by launching an external user-agent. The client can
custom redirect result page that puts the verification code in the capture the response by providing a redirection URI with a custom
title. URI scheme (registered with the operating system to invoke the
client application), or by providing a redirection URI pointing to
a server-hosted resource under the client's control which puts the
response in the user-agent window title (from which the client can
obtain the response by polling the user-agnet window, looking for
a window title change).
o Use an embedded user-agent and obtain the redirection URI. This o Utilize the end-user authorization endpoint as described in
works with the web server flow and user-agent flow. Section 3 by using an embedded user-agent. The client obtains the
response by directly communicating with the embedded user-agent.
o Use the username and password flow and prompt the end-users for o Prompt end-users for their basic credentials (username and
their credentials. This is generally discouraged as it hands the password) and use them directly to obtain an access token. This
end-user's password directly to the 3rd party and may not work is generally discouraged as it hands the end-user's password
with some authentication schemes. directly to the 3rd party and is limited to basic credentials.
When choosing between launching an external browser and an embedded When choosing between launching an external browser and an embedded
user-agent, developers should consider the following: user-agent, developers should consider the following:
o External user-agents may improve completion rate as the end-user o External user-agents may improve completion rate as the end-user
may already be logged-in and not have to re-authenticate. may already be logged-in and not have to re-authenticate.
o Embedded user-agents often offer a better end-user flow, as they o Embedded user-agents often offer a better end-user flow, as they
remove the need to switch context and open new windows. remove the need to switch context and open new windows.
o Embedded user-agents are less secure because users are o Embedded user-agents are less secure because users are
authenticating in unidentified window without access to the authenticating in unidentified window without access to the
protections offered by many user-agents. protections offered by many user-agents.
3. Client Credentials 1.4.4. Autonomous
When requesting access from the authorization server, the client Autonomous clients act on their own behalf (the client is also the
identifies itself using a set of client credentials. The client resource owner), or utilize existing trust relationship or framework
credentials include a client identifier and an OPTIONAL symmetric to establish authorization without directly involving the resource
shared secret. The means through which the client obtains these owner.
credentials are beyond the scope of this specification, but usually
involve registration with the authorization server.
The client identifier is used by the authorization server to Autonomous clients can be implemented in different ways based on
establish the identity of the client for the purpose of presenting their requirements and the existing trust framework they rely upon.
information to the resource owner prior to granting access, as well Autonomous clients can:
as for providing different service levels to different clients. They
can also be used to block unauthorized clients from requesting o Obtain an access token by authenticating with the authorization
access. server using their client credentials. The scope of the access
token is limited to the protected resources under the control of
the client.
o Use an existing access grant expressed as an assertion using an
assertion format supported by the authorization server. Using
assertions requires the client to obtain a assertion (such as a
SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer
or to self-issue an assertion. The assertion format, the process
by which the assertion is obtained, and the method of validating
the assertion are defined by the assertion issuer and the
authorization server, and are beyond the scope of this
specification.
2. Client Credentials
When interacting with the authorization server, the client identifies
itself using a set of client credentials. The client credentials
include a client identifier and MAY include a secret or other means
for the authorization server to authenticate the client.
The means through which the client obtains its credentials are beyond
the scope of this specification, but usually involve registration
with the authorization server. [[ OAuth Discovery provides one way of
obtaining basic client credentials ]]
Due to the nature of some clients, authorization servers SHOULD NOT Due to the nature of some clients, authorization servers SHOULD NOT
make assumptions about the confidentiality of client credentials make assumptions about the confidentiality of client credentials
without establishing trust with the client operator. Authorization without establishing trust with the client operator. Authorization
servers SHOULD NOT issue client secrets to clients incapable of servers SHOULD NOT issue client secrets to clients incapable of
keeping their secrets confidential. keeping their secrets confidential.
3.1. Client Authentication This specification provides one mean of authenticating the client
using a set of basic client credentials. The authorization server
MAY authenticate the client using any desired authentication scheme.
The token endpoint requires the client to authenticate itself to the 2.1. Basic Client Credentials
authorization server. This is done by including the client
identifier (and optional secret) in the request. The client The basic client credentials include a client identifier and an
identifier and secret are included in the request using two request OPTIONAL matching shared symmetric secret. The client identifier and
parameters: "client_id" and "client_secret". secret are included in the request using the HTTP Basic
authentication scheme as defined in [RFC2617] by including the client
identifier as the username and secret as the password.
For example (line breaks are for display purposes only): For example (line breaks are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
type=web_server&client_id=s6BhdRkqt3& type=web_server&code=i1WsRn1uB1&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The client MAY include the client credentials using an HTTP Alternatively, the client MAY include the credentials using the
authentication scheme which supports authenticating using a username following request parameters:
and password, instead of using the "client_id" and "client_secret"
request parameters. Including the client credentials using an HTTP
authentication scheme fulfills the requirements of including the
parameters as defined by the various flows.
The client MUST NOT include the client credentials using more than client_id
one mechanism. If more than one mechanism is used, regardless if the REQUIRED. The client identifier.
credentials are identical, the server MUST reply with an HTTP 400
status code (Bad Request) and include the "multiple-credentials"
error message.
The authorization server MUST accept the client credentials using client_secret REQUIRED if the client identifier has a matching
both the request parameters, and the HTTP Basic authentication scheme secret.
as defined in [RFC2617]. The authorization server MAY support
additional HTTP authentication schemes.
For example (line breaks are for display purposes only): For example (line breaks are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
type=web_server&code=i1WsRn1uB1& type=web_server&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
4. Establishing Resource Owner Authorization The client MAY include the client credentials using other HTTP
authentication schemes which support authenticating using a username
Before the client can obtain an access token, it must first attain and password. The client MUST NOT include the client credentials
authorization from the resource owner. The methods through which the using more than one mechanism. If more than one mechanism is used,
client attains authorization are codified in the various regardless whether the credentials are identical or valid, the server
authorization flows defined in Section 5, and depends on the client MUST reply with an HTTP 400 status code (Bad Request) and include the
type and its trust relationship with the resource owner. "multiple_credentials" error code.
Resource owner authorization can be expressed in multiple ways: a
verification code obtained through direct interaction with an end-
user, the resource owner credentials (or the client credentials when
the client is also the resource owner) obtained through a trust
relationship with the resource owner, or an assertion obtained
through means beyond the scope of this specification.
4.1. Verification Code The authorization server MUST accept the client credentials using
both the request parameters, and the HTTP Basic authentication
scheme. The authorization server MAY support additional
authentication schemes.
When an end-user is involved, the client attains authorization in the 3. Obtaining End-User Authorization
form of a verification code by sending the end-user to the
authorization server to review and grant the request. The client
sends the end-user by directing the end-user's user-agent to the
authorization server's end-user authorization endpoint.
4.1.1. End-User Authorization Endpoint When the client interacts with an end-user, the end-user MUST first
grant the client authorization to access its protected resources.
Once obtained, the end-user access grant is expressed as an
authorization code which the client uses to obtain an access token.
To obtain an end-user authorization, the client sends the end-user to
the end-user authorization endpoint.
When directed to the end-user authorization endpoint, the end-user At the end-user authorization endpoint, the end-user first
first authenticates with the authorization server, and then grants or authenticates with the authorization server, and then grants or
denies the access request. The way in which the authorization server denies the access request. The way in which the authorization server
authenticates the end-user (e.g. username and password login, OpenID, authenticates the end-user (e.g. username and password login, OpenID,
session cookies) and in which the authorization server obtains the session cookies) and in which the authorization server obtains the
end-user's authorization, including whether it uses a secure channel end-user's authorization, including whether it uses a secure channel
such as TLS, is beyond the scope of this specification. However, the such as TLS, is beyond the scope of this specification. However, the
authorization server MUST first verify the identity of the end-user. authorization server MUST first verify the identity of the end-user.
The location of the end-user authorization endpoint can be found in The location of the end-user authorization endpoint can be found in
the service documentation, or can be obtained by using [[ OAuth the service documentation, or can be obtained by using [[ OAuth
Discovery ]]. The end-user authorization endpoint URI MAY include a Discovery ]]. The end-user authorization endpoint URI MAY include a
skipping to change at page 18, line 12 skipping to change at page 15, line 12
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]:
type type
REQUIRED. The client type (user-agent or web server). REQUIRED. The client type (user-agent or web server).
Determines how the authorization server delivers the Determines how the authorization server delivers the
authorization response back to the client. The parameter value authorization response back to the client. The parameter value
MUST be set to "web_server" or "user_agent". MUST be set to "web_server" or "user_agent".
client_id client_id
REQUIRED. The client identifier as described in Section 3. REQUIRED. The client identifier as described in Section 2.
redirect_uri redirect_uri
REQUIRED, unless a redirection URI has been established between REQUIRED, unless a redirection URI has been established between
the client and authorization server via other means. An the client and authorization server via other means. An
absolute URI to which the authorization server will redirect absolute URI to which the authorization server will redirect
the user-agent to when the end-user authorization step is the user-agent to when the end-user authorization step is
completed. The authorization server SHOULD require the client completed. The authorization server SHOULD require the client
to pre-register their redirection URI. Authorization servers to pre-register their redirection URI. Authorization servers
MAY restrict the redirection URI to not include a query MAY restrict the redirection URI to not include a query
component as defined by [RFC3986] section 3. component as defined by [RFC3986] section 3.
skipping to change at page 19, line 15 skipping to change at page 16, line 15
the client identifier. [[ provide guidance on how to perform matching the client identifier. [[ provide guidance on how to perform matching
]] ]]
The authorization server authenticates the end-user and obtains an The authorization server authenticates the end-user and obtains an
authorization decision (by asking the end-user or by establishing authorization decision (by asking the end-user or by establishing
approval via other means). When a decision has been established, the approval via other means). When a decision has been established, the
authorization server directs the end-user's user-agent to the authorization server directs the end-user's user-agent to the
provided client redirection URI using an HTTP redirection response, provided client redirection URI using an HTTP redirection response,
or by other means available to it via the end-user's user-agent. or by other means available to it via the end-user's user-agent.
4.1.1.1. Authorization Server Response 3.1. Authorization Server Response
If the end-user grants the access request, the authorization server If the end-user grants the access request, the authorization server
issues an access token, a verification code, or both, and delivers issues an access token, an authorization code, or both, and delivers
them to the client by adding the following parameters to the them to the client by adding the following parameters to the
redirection URI: redirection URI:
code code
REQUIRED if the client type is "web_server", otherwise REQUIRED if the client type is "web_server", otherwise
OPTIONAL. The verification code generated by the authorization OPTIONAL. The authorization code generated by the
server. The verification code SHOULD expire shortly after it authorization server. The authorization code SHOULD expire
is issued and allowed for a single use. The verification code shortly after it is issued and allowed for a single use. The
is bound to the client identifier and redirection URI. authorization code is bound to the client identifier and
redirection URI.
access_token access_token
REQUIRED if the client type is "user_agent", otherwise MUST NOT REQUIRED if the client type is "user_agent", otherwise MUST NOT
be included. The access token. be included. The access token.
expires_in expires_in
OPTIONAL. The duration in seconds of the access token lifetime OPTIONAL. The duration in seconds of the access token lifetime
if an access token is included. if an access token is included.
state state
skipping to change at page 20, line 36 skipping to change at page 17, line 36
parameters to the redirection URI fragment component using the parameters to the redirection URI fragment component using the
"application/x-www-form-urlencoded" format as defined by "application/x-www-form-urlencoded" format as defined by
[W3C.REC-html401-19991224]. [[ replace form-encoded with JSON? ]] [W3C.REC-html401-19991224]. [[ replace form-encoded with JSON? ]]
For example, the authorization server redirects the end-user's user- For example, the authorization server redirects the end-user's user-
agent by sending the following HTTP response: agent by sending the following HTTP response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: http://example.com/rd#access_token=FJQbwq9&expires_in=3600 Location: http://example.com/rd#access_token=FJQbwq9&expires_in=3600
4.2. Resource Owner Credentials 4. Obtaining an Access Token
While OAuth seeks to eliminate the need for resource owners to share
their credentials with the client, possesion of the resource owner
credentials constitute an authorization grant (if supported by the
authorization server). Resource owner credentials should only be
used when there is a high degree of trust between the resource owner
the client.
In cases where the client is also the resource owner, the client
credentials can be used to obtain an access token provisioned for
accessing the client's protected resources.
4.3. Assertion
Assertions enable the client to utilize existing trust relationships
or different authorization constructs to obtain an access token.
They provide a bridge between OAuth and other trust frameworks. The
authorization grant represented by an assertion depends on the
assertion type, its content, and how it was issued, which are beyond
the scope of this specification.
5. Obtaining an Access Token
The client obtains an access token by authenticating with the The client obtains an access token by authenticating with the
authorization server and presenting its authorization grant. authorization server and presenting its access grant.
In many cases it is desirable to issue access tokens with a shorter
lifetime than the duration of the authorization grant. However, it
may be undesirable to require the resource owner to authorize the
request again. Instead, the authorization server issues a refresh
token in addition to the access token. When the access token
expires, the client can request a new access token without involving
the resource owner as long as the authorization grant is still valid.
The token refresh method is described in Section 5.1.4.
5.1. Token Endpoint
After obtaining authorization from the resource owner, clients After obtaining authorization from the resource owner, clients
request an access token from the authorization server's token request an access token from the authorization server's token
endpoint. When requesting an access token, the client authenticates endpoint. When requesting an access token, the client authenticates
with the authorization server and includes the authorization grant with the authorization server and includes the access grant (in the
(in the form of a verification code, resource owner credentials, an form of an authorization code, resource owner credentials, an
assertion, or a refresh token). assertion, or a refresh token).
The location of the token endpoint can be found in the service The location of the token endpoint can be found in the service
documentation, or can be obtained by using [[ OAuth Discovery ]]. documentation, or can be obtained by using [[ OAuth Discovery ]].
The token endpoint URI MAY include a query component, which must be The token endpoint URI MAY include a query component, which must be
retained when adding additional query parameters. retained when adding additional query parameters.
Since requests to the token endpoint result in the transmission of Since requests to the token endpoint result in the transmission of
plain text credentials in the HTTP request and response, the plain text credentials in the HTTP request and response, the
authorization server MUST require the use of a transport-layer authorization server MUST require the use of a transport-layer
mechanism when sending requests to the token endpoints. Servers MUST mechanism when sending requests to the token endpoints. Servers MUST
support TLS 1.2 as defined in [RFC5246] and MAY support addition support TLS 1.2 as defined in [RFC5246] and MAY support addition
mechanisms with equivalent protections. mechanisms with equivalent protections.
The client obtains an access token by constructing a token request. The client requests an access token by constructing a token request
The client constructs the request URI by: and making an HTTP "POST" request. The client constructs the request
URI by adding its client credentials to the request as described in
Section 2, and includes the following parameters using the
"application/x-www-form-urlencoded" format in the HTTP request
entity-body:
o Adding its client credentials to the request as described in grant_type
Section 3.1. For example, if the client uses a set of basic REQUIRED. The access grand type included in the request.
client credentials, it adds the "client_id" and "client_secret" Value MUST be one of "authorization_code",
parameters to the request (or uses the HTTP Basic authentication "user_basic_credentials", "assertion", "refresh_token", or
scheme). "none" (which indicates the client is acting on behalf of
itself).
o Adding the authorization grand in the form of a verification code, scope
resource owner credentials, an assertion, or refresh token. If OPTIONAL. The scope of the access request expressed as a list
the client is acting on behalf of itself (the client is also the of space-delimited strings. The value of the "scope" parameter
resource owner), no additional information is needed. The is defined by the authorization server. If the value contains
authorization grant is added to the request URI query component multiple space-delimited strings, their order does not matter,
using the "application/x-www-form-urlencoded" format as described and each string adds an additional access range to the
below. requested scope. If the access grant being used already
represents an approved scope (e.g. authorization code,
assertion), the requested scope MUST be equal or lesser than
the scope previously granted.
5.1.1. Verification Code In addition, the client MUST include the appropriate parameters
listed for the selected access grant type as described in
Section 4.1.
The client includes the verification code using following parameters: 4.1. Access Grant Parameters
4.1.1. Authorization Code
The client includes the authorization code using the
"authorization_code" access grant type and the following parameters:
code code
REQUIRED. The verification code received from the REQUIRED. The authorization code received from the
authorization server. authorization server.
redirect_uri redirect_uri
REQUIRED. The redirection URI used in the initial request. REQUIRED. The redirection URI used in the initial request.
For example, the client makes the following HTTPS request (line For example, the client makes the following HTTPS request (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 Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3& grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1& client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST verify that the verification code, The authorization server MUST verify that the authorization code,
client identity, client secret, and redirection URI are all valid and client identity, client secret, and redirection URI are all valid and
match its stored association. If the request is valid, the match its stored association. If the request is valid, the
authorization server issues a successful response as described in authorization server issues a successful response as described in
Section 5.1.5. Section 4.2.
5.1.2. Resource Owner Credentials 4.1.2. Resource Owner Basic Credentials
The client includes the resource owner credentials using the The client includes the resource owner credentials using the
following parameters: [[ add internationalization consideration for following parameters: [[ add internationalization consideration for
username and password ]] username and password ]]
username username
REQUIRED. The end-user's username. REQUIRED. The end-user's username.
password password
REQUIRED. The end-user's password. REQUIRED. The end-user's password.
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the "scope" parameter
is defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the
requested scope.
For example, the client makes the following HTTPS request (line For example, the client makes the following HTTPS request (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 Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3&client_secret= grant_type=user_basic&client_id=s6BhdRkqt3&
47HDu8s&username=johndoe&password=A3ddj3w client_secret=47HDu8s&username=johndoe&password=A3ddj3w
The authorization server MUST validate the client credentials and The authorization server MUST validate the client credentials and
end-user credentials and if valid issues an access token response as end-user credentials and if valid issues an access token response as
described in Section 5.1.5. described in Section 4.2.
If the client is acting on behalf of itself (the client is also the
resource owner), the client authentication alone suffice and the
"username" and "password" parameters MUST NOT be used.
5.1.3. Assertion 4.1.3. Assertion
The client includes the assertion using the following parameters: The client includes the assertion using the following parameters:
assertion_type assertion_type
REQUIRED. The format of the assertion as defined by the REQUIRED. The format of the assertion as defined by the
authorization server. The value MUST be an absolute URI. authorization server. The value MUST be an absolute URI.
assertion assertion
REQUIRED. The assertion. REQUIRED. The assertion.
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the "scope" parameter
is defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the
requested scope.
For example, the client makes the following HTTPS request (line For example, the client makes the following HTTPS request (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 Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3&client_secret=diejdsks& grant_type=assertion&client_id=s6BhdRkqt3&client_secret=diejdsks&
assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&
assertion=PHNhbWxwOl...[ommited for brevity]...ZT4%3D assertion=PHNhbWxwOl...[ommited for brevity]...ZT4%3D
The authorization server MUST validate the assertion and if valid The authorization server MUST validate the assertion and if valid
issues an access token response as described in Section 5.1.5. The issues an access token response as described in Section 4.2. The
authorization server SHOULD NOT issue a refresh token. authorization server SHOULD NOT issue a refresh token.
Authorization servers SHOULD issue access tokens with a limited Authorization servers SHOULD issue access tokens with a limited
lifetime and require clients to refresh them by requesting a new lifetime and require clients to refresh them by requesting a new
access token using the same assertion if it is still valid. access token using the same assertion if it is still valid.
Otherwise the client MUST obtain a new valid assertion. Otherwise the client MUST obtain a new valid assertion.
5.1.4. Refresh Token 4.1.4. Refresh Token
Token refresh is used when the lifetime of an access token is shorter
than the lifetime of the authorization grant. It enables the client
to obtain a new access token without having to go through the
authorization flow again or involve the resource owner.
The client includes the refresh token using the following parameters: The client includes the refresh token using the following parameters:
refresh_token refresh_token
REQUIRED. The refresh token associated with the access token REQUIRED. The refresh token associated with the access token
to be refreshed. to be refreshed.
For example, the client makes the following HTTPS request (line break For example, the client makes the following HTTPS request (line break
are for display purposes only): are for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM grant_type=refresh_token&client_id=s6BhdRkqt3&
&refresh_token=n4E9O119d client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
The authorization server MUST verify the client credentials, the The authorization server MUST verify the client credentials, the
validity of the refresh token, and that the resource owner's validity of the refresh token, and that the resource owner's
authorization is still valid. If the request is valid, the authorization is still valid. If the request is valid, the
authorization server issues an access token response as described in authorization server issues an access token response as described in
Section 5.1.5. The authorization server MAY issue a new refresh Section 4.2. The authorization server MAY issue a new refresh token
token in which case the client MUST NOT use the previous refresh in which case the client MUST NOT use the previous refresh token and
token and replace it with the newly issued refresh token. replace it with the newly issued refresh token.
5.1.5. Access Token Response 4.2. Access Token Response
After receiving and verifying a valid and authorized access token After receiving and verifying a valid and authorized access token
request from the client, the authorization server issues the access request from the client, the authorization server issues the access
token and optional refresh token, and constructs the response by token and optional refresh token, and constructs the response by
adding the following parameters to the entity body of the HTTP adding the following parameters to the entity body of the HTTP
response with a 200 status code (OK): response with a 200 status code (OK):
The token response contains the following parameters: The token response contains the following parameters:
access_token access_token
REQUIRED. The access token issued by the authorization server. REQUIRED. The access token issued by the authorization server.
expires_in expires_in
OPTIONAL. The duration in seconds of the access token OPTIONAL. The duration in seconds of the access token
lifetime. lifetime.
refresh_token refresh_token
OPTIONAL. The refresh token used to obtain new access tokens OPTIONAL. The refresh token used to obtain new access tokens
using the same end-user access grant as described in using the same end-user access grant as described in
Section 5.1.4. Section 4.1.4.
scope scope
OPTIONAL. The scope of the access token as a list of space- OPTIONAL. The scope of the access token as a list of space-
delimited strings. The value of the "scope" parameter is delimited strings. The value of the "scope" parameter is
defined by the authorization server. If the value contains defined by the authorization server. If the value contains
multiple space-delimited strings, their order does not matter, multiple space-delimited strings, their order does not matter,
and each string adds an additional access range to the and each string adds an additional access range to the
requested scope. requested scope.
The parameters are including in the entity body of the HTTP response The parameters are including in the entity body of the HTTP response
skipping to change at page 26, line 29 skipping to change at page 22, line 29
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"access_token":"SlAV32hkKG", "access_token":"SlAV32hkKG",
"expires_in":3600, "expires_in":3600,
"refresh_token":"8xLOxBtZp8" "refresh_token":"8xLOxBtZp8"
} }
5.1.6. Error Response 4.3. Error Response
If the token request is invalid or unauthorized, the authorization If the token request is invalid or unauthorized, the authorization
server constructs the response by adding the following parameter to server constructs the response by adding the following parameter to
the entity body of the HTTP response with a a 400 status code (Bad the entity body of the HTTP response with a a 400 status code (Bad
Request) using the "application/json" media type: Request) using the "application/json" media type:
error error
REQUIRED. The error code as described in Section 5.1.6.1. REQUIRED. The error code as described in Section 4.3.1.
For example: For example:
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"error":"incorrect_client_credentials" "error":"incorrect_client_credentials"
} }
5.1.6.1. Error Codes 4.3.1. Error Codes
[[ expalain each error code: ]] [[ expalain each error code: ]]
o "redirect_uri_mismatch" o "redirect_uri_mismatch"
o "bad_verification_code" o "bad_authorization_code"
o "incorrect_client_credentials" o "invalid_client_credentials"
o "unauthorized_client'" - The client is not permitted to use this o "unauthorized_client'" - The client is not permitted to use this
authorization grant type. access grant type.
o "invalid_assertion" o "invalid_assertion"
o "unknown_format" o "unknown_format"
o "authorization_expired" o "authorization_expired"
6. Accessing a Protected Resource o "multiple_credentials"
o "invalid_user_credentials"
5. Accessing a Protected Resource
Clients access protected resources by presenting an access token to Clients access protected resources by presenting an access token to
the resource server. the resource server.
For example: For example:
GET /resource HTTP/1.1 GET /resource HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Token token="vF9dft4qmT" Authorization: Token token="vF9dft4qmT"
skipping to change at page 28, line 14 skipping to change at page 24, line 18
The methods used by the resource server to validate the access token The methods used by the resource server to validate the access token
are beyond the scope of this specification, but generally involve an are beyond the scope of this specification, but generally involve an
interaction or coordination between the resource server and interaction or coordination between the resource server and
authorization server. authorization server.
The resource server MUST validate the access token and ensure it has The resource server MUST validate the access token and ensure it has
not expired and that its scope covers the requested resource. If the not expired and that its scope covers the requested resource. If the
token expired or is invalid, the resource server MUST reply with an token expired or is invalid, the resource server MUST reply with an
HTTP 401 status code (Unauthorized) and include the HTTP HTTP 401 status code (Unauthorized) and include the HTTP
"WWW-Authenticate" response header as described in Section 7.1. "WWW-Authenticate" response header field as described in Section 6.
For example: For example:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm='Service', error='token_expired' WWW-Authenticate: Token realm='Service', error='token_expired'
Clients make authenticated token requests using the "Authorization" Clients make authenticated token requests using the "Authorization"
request header field as described in Section 6.1. Alternatively, request header field as described in Section 5.1. Alternatively,
clients MAY include the access token using the HTTP request URI in clients MAY include the access token using the HTTP request URI in
the query component as described in Section 6.2, or in the HTTP body the query component as described in Section 5.2, or in the HTTP body
when using the "application/x-www-form-urlencoded" content type as when using the "application/x-www-form-urlencoded" content type as
described in Section 6.3. described in Section 5.3.
Clients SHOULD only use the request URI or body when the Clients SHOULD only use the request URI or body when the
"Authorization" request header field is not available, and MUST NOT "Authorization" request header field is not available, and MUST NOT
use more than one method in each request. [[ specify error ]] use more than one method in each request. [[ specify error ]]
6.1. The Authorization Request Header 5.1. The Authorization Request Header Field
The "Authorization" request header field is used by clients to make The "Authorization" request header field is used by clients to make
authenticated token requests. The client uses the "token" attribute authenticated token requests. The client uses the "token" attribute
to include the access token in the request. to include the access token in the request.
The "Authorization" header field uses the framework defined by The "Authorization" header field uses the framework defined by
[RFC2617] as follows: [RFC2617] as follows:
credentials = "Token" RWS access-token [ CS 1#auth-param ] credentials = "Token" RWS access-token [ CS 1#auth-param ]
access-token = "token" "=" <"> token <"> access-token = "token" "=" <"> token <">
CS = OWS "," OWS CS = OWS "," OWS
6.2. URI Query Parameter 5.2. URI Query Parameter
When including the access token in the HTTP request URI, the client When including the access token in the HTTP request URI, the client
adds the access token to the request URI query component as defined adds the access token to the request URI query component as defined
by [RFC3986] using the "oauth_token" parameter. by [RFC3986] using the "oauth_token" parameter.
For example, the client makes the following HTTPS request: For example, the client makes the following HTTPS request:
GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 GET /resource?oauth_token=vF9dft4qmT HTTP/1.1
Host: server.example.com Host: server.example.com
The HTTP request URI query can include other request-specific The HTTP request URI query can include other request-specific
parameters, in which case, the "oauth_token" parameters SHOULD be parameters, in which case, the "oauth_token" parameters SHOULD be
appended following the request-specific parameters, properly appended following the request-specific parameters, properly
separated by an "&" character (ASCII code 38). separated by an "&" character (ASCII code 38).
The resource server MUST validate the access token and ensure it has The resource server MUST validate the access token and ensure it has
not expired and its scope includes the requested resource. If the not expired and its scope includes the requested resource. If the
resource expired or is not valid, the resource server MUST reply with resource expired or is not valid, the resource server MUST reply with
an HTTP 401 status code (Unauthorized) and include the HTTP an HTTP 401 status code (Unauthorized) and include the HTTP
"WWW-Authenticate" response header as described in Section 7.1. "WWW-Authenticate" response header field as described in Section 6.
6.3. Form-Encoded Body Parameter 5.3. Form-Encoded Body Parameter
When including the access token in the HTTP request entity-body, the When including the access token in the HTTP request entity-body, the
client adds the access token to the request body using the client adds the access token to the request body using the
"oauth_token" parameter. The client can use this method only if the "oauth_token" parameter. The client can use this method only if the
following REQUIRED conditions are met: following REQUIRED conditions are met:
o The entity-body is single-part. o The entity-body is single-part.
o The entity-body follows the encoding requirements of the o The entity-body follows the encoding requirements of the
"application/x-www-form-urlencoded" content-type as defined by "application/x-www-form-urlencoded" content-type as defined by
skipping to change at page 30, line 4 skipping to change at page 26, line 10
The entity-body can include other request-specific parameters, in The entity-body can include other request-specific parameters, in
which case, the "oauth_token" parameters SHOULD be appended following which case, the "oauth_token" parameters SHOULD be appended following
the request-specific parameters, properly separated by an "&" the request-specific parameters, properly separated by an "&"
character (ASCII code 38). character (ASCII code 38).
For example, the client makes the following HTTPS request: For example, the client makes the following HTTPS request:
POST /resource HTTP/1.1 POST /resource HTTP/1.1
Host: server.example.com Host: server.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
oauth_token=vF9dft4qmT oauth_token=vF9dft4qmT
The resource server MUST validate the access token and ensure it has The resource server MUST validate the access token and ensure it has
not expired and its scope includes the requested resource. If the not expired and its scope includes the requested resource. If the
resource expired or is not valid, the resource server MUST reply with resource expired or is not valid, the resource server MUST reply with
an HTTP 401 status code (Unauthorized) and include the HTTP an HTTP 401 status code (Unauthorized) and include the HTTP
"WWW-Authenticate" response header as described in Section 7.1. "WWW-Authenticate" response header field as described in Section 6.
7. Identifying a Protected Resource 6. The WWW-Authenticate Response Header Field
Clients access protected resources after locating the appropriate Clients access protected resources after locating the appropriate
end-user authorization endpoint and token endpoint and obtaining an end-user authorization endpoint and token endpoint and obtaining an
access token. In many cases, interacting with a protected resource access token. In many cases, interacting with a protected resource
requires prior knowledge of the protected resource properties and requires prior knowledge of the protected resource properties and
methods, as well as its authentication requirements (i.e. methods, as well as its authentication requirements (i.e.
establishing client identity, locating the end-user authorization and establishing client identity, locating the end-user authorization and
token endpoints). token endpoints).
However, there are cases in which clients are unfamiliar with the However, there are cases in which clients are unfamiliar with the
protected resource, including whether the resource requires protected resource, including whether the resource requires
authentication. When clients attempt to access an unfamiliar authentication. When clients attempt to access an unfamiliar
protected resource without an access token, the resource server protected resource without an access token, the resource server
denies the request and informs the client of the required credentials denies the request and informs the client of the required credentials
using an HTTP authentication challenge. using an HTTP authentication challenge.
In addition, when receiving an invalid authenticated request, the In addition, when receiving an invalid authenticated request, the
resource server issues an authentication challenge including the resource server issues an authentication challenge including the
error type and message. error type and message.
7.1. The WWW-Authenticate Response Header
A resource server receiving a request for a protected resource A resource server receiving a request for a protected resource
without a valid access token MUST respond with a 401 (Unauthorized) without a valid access token MUST respond with a 401 (Unauthorized)
or 403 (Forbidden) HTTP status code, and include at least one "Token" or 403 (Forbidden) HTTP status code, and include at least one "Token"
"WWW-Authenticate" response header field challenge. "WWW-Authenticate" response header field challenge.
The "WWW-Authenticate" header field uses the framework defined by The "WWW-Authenticate" header field uses the framework defined by
[RFC2617] as follows: [RFC2617] as follows:
challenge = "Token" RWS token-challenge challenge = "Token" RWS token-challenge
skipping to change at page 31, line 13 skipping to change at page 27, line 19
[ CS 1#auth-param ] [ CS 1#auth-param ]
error = "error" "=" <"> token <"> error = "error" "=" <"> token <">
The "realm" attribute is used to provide the protected resources The "realm" attribute is used to provide the protected resources
partition as defined by [RFC2617]. partition as defined by [RFC2617].
The "error" attribute is used to inform the client the reason why an The "error" attribute is used to inform the client the reason why an
access request was declined. [[ Add list of error codes ]] access request was declined. [[ Add list of error codes ]]
8. Security Considerations 7. Security Considerations
[[ Todo ]] [[ todo ]]
9. IANA Considerations 8. IANA Considerations
[[ Not Yet ]] [[ Not Yet ]]
Appendix A. Contributors Appendix A. Examples
[[ todo ]]
Appendix B. Contributors
The following people contributed to preliminary versions of this The following people contributed to preliminary versions of this
document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland
(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),
Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and
concepts within are a product of the OAuth community, WRAP community, concepts within are a product of the OAuth community, WRAP community,
and the OAuth Working Group. and the OAuth Working Group.
The OAuth Working Group has dozens of very active contributors who The OAuth Working Group has dozens of very active contributors who
proposed ideas and wording for this document, including: [[ If your proposed ideas and wording for this document, including: [[ If your
name is missing or you think someone should be added here, please name is missing or you think someone should be added here, please
send Eran a note - don't be shy ]] send Eran a note - don't be shy ]]
Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah
Culver, Igor Faynberg, George Fletcher, Evan Gilbert, Justin Hart, Culver, Igor Faynberg, George Fletcher, Evan Gilbert, Justin Hart,
John Kemp, Torsten Lodderstedt, Eve Maler, James Manger, Chuck John Kemp, Torsten Lodderstedt, Eve Maler, James Manger, Chuck
Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre,
Marius Scurtescu, Justin Smith, and Franklin Tse. Marius Scurtescu, Justin Smith, and Franklin Tse.
Appendix B. Acknowledgements Appendix C. Acknowledgements
[[ Add OAuth 1.0a authors + WG contributors ]] [[ Add OAuth 1.0a authors + WG contributors ]]
Appendix C. Document History Appendix D. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
-08
o Renamed verification code to authorization code.
o Revised terminology, structured section, added new terms.
o Changed flows to profiles and moved to introduction.
o Added support for access token rescoping.
o Cleaned up client credentials section.
o New introduction overview.
o Added error code for invalid username and password, and renamed
error code to be more consistent.
o Added access grant type parameter to token endpoint.
-07 -07
o Major rewrite of entire document structure. o Major rewrite of entire document structure.
o Removed device profile. o Removed device profile.
o Added verification code support to user-agent flow. o Added verification code support to user-agent flow.
o Removed multiple formats support, leaving JSON as the only format. o Removed multiple formats support, leaving JSON as the only format.
skipping to change at page 34, line 30 skipping to change at page 31, line 9
o Editorial changes based on feedback from Brian Eaton, Bill Keenan, o Editorial changes based on feedback from Brian Eaton, Bill Keenan,
and Chuck Mortimore. and Chuck Mortimore.
o Changed device flow "type" parameter values and switch to use only o Changed device flow "type" parameter values and switch to use only
the token endpoint. the token endpoint.
-00 -00
o Initial draft based on a combination of WRAP and OAuth 1.0a. o Initial draft based on a combination of WRAP and OAuth 1.0a.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.ietf-httpbis-p1-messaging] [I-D.ietf-httpbis-p1-messaging]
Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
"HTTP/1.1, part 1: URIs, Connections, and Message "HTTP/1.1, part 1: URIs, Connections, and Message
Parsing", draft-ietf-httpbis-p1-messaging-09 (work in Parsing", draft-ietf-httpbis-p1-messaging-09 (work in
progress), March 2010. progress), March 2010.
[NIST FIPS-180-3] [NIST FIPS-180-3]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
skipping to change at page 35, line 46 skipping to change at page 32, line 24
[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]
Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
10.2. Informative References 9.2. Informative References
[I-D.hammer-oauth] [I-D.hammer-oauth]
Hammer-Lahav, E., "The OAuth 1.0 Protocol", Hammer-Lahav, E., "The OAuth 1.0 Protocol",
draft-hammer-oauth-10 (work in progress), February 2010. draft-hammer-oauth-10 (work in progress), February 2010.
[I-D.hardt-oauth] [I-D.hardt-oauth]
Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web
Resource Authorization Profiles", draft-hardt-oauth-01 Resource Authorization Profiles", draft-hardt-oauth-01
(work in progress), January 2010. (work in progress), January 2010.
 End of changes. 147 change blocks. 
584 lines changed or deleted 462 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/