draft-ietf-oauth-v2-19.txt   draft-ietf-oauth-v2-20.txt 
Network Working Group E. Hammer-Lahav, Ed. Network Working Group E. Hammer-Lahav, Ed.
Internet-Draft Yahoo! Internet-Draft Yahoo!
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) D. Recordon
Intended status: Standards Track Facebook Intended status: Standards Track Facebook
Expires: January 26, 2012 D. Hardt Expires: January 26, 2012 D. Hardt
Microsoft Microsoft
July 25, 2011 July 25, 2011
The OAuth 2.0 Authorization Protocol The OAuth 2.0 Authorization Protocol
draft-ietf-oauth-v2-19 draft-ietf-oauth-v2-20
Abstract Abstract
The OAuth 2.0 authorization protocol enables a third-party The OAuth 2.0 authorization protocol enables a third-party
application to obtain limited access to an HTTP service, either on application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. third-party application to obtain access on its own behalf.
Status of this Memo Status of this Memo
skipping to change at page 12, line 11 skipping to change at page 12, line 11
accomplished using a self-issued or third-party-issued assertion, or accomplished using a self-issued or third-party-issued assertion, or
by the authorization server performing client discovery using a by the authorization server performing client discovery using a
trusted channel. trusted channel.
2.1. Client Types 2.1. Client Types
OAuth defines two client types, based on their ability to OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e. ability to authenticate securely with the authorization server (i.e. ability to
maintain the confidentiality of their client credentials): maintain the confidentiality of their client credentials):
private confidential
Clients capable of maintaining the confidentiality of their Clients capable of maintaining the confidentiality of their
credentials (e.g. client implemented on a secure server with credentials (e.g. client implemented on a secure server with
restricted access to the client credentials), or capable of secure restricted access to the client credentials), or capable of secure
client authentication using other means. client authentication using other means.
public public
Clients incapable of maintaining the confidentiality of their Clients incapable of maintaining the confidentiality of their
credentials (e.g. clients executing on the resource owner's device credentials (e.g. clients executing on the resource owner's device
such as an installed native application or a user-agent-based such as an installed native application or a user-agent-based
application), and incapable of secure client authentication via application), and incapable of secure client authentication via
any other mean. any other mean.
The client type designation is based on the authorization server's The client type designation is based on the authorization server's
definition of secure authentication and its acceptable exposure definition of secure authentication and its acceptable exposure
levels of client credentials. levels of client credentials.
This specification has been designed around the following client This specification has been designed around the following client
profiles: profiles:
web application web application
A web application is a private client running on a web server. A web application is a confidential client running on a web
Resource owners access the client via an HTML user interface server. Resource owners access the client via an HTML user
rendered in a user-agent on the resource owner's device. The interface rendered in a user-agent on the resource owner's device.
client credentials as well as any access token issued to the The client credentials as well as any access token issued to the
client are stored on the web server and are not exposed to or client are stored on the web server and are not exposed to or
accessible by the resource owner. accessible by the resource owner.
user-agent-based application user-agent-based application
A user-agent-based application is a public client in which the A user-agent-based application is a public client in which the
client code is downloaded from a web server and executes within a client code is downloaded from a web server and executes within a
user-agent on the resource owner's device. Protocol data and user-agent on the resource owner's device. Protocol data and
credentials are easily accessible (and often visible) to the credentials are easily accessible (and often visible) to the
resource owner. Since such applications reside within the user- resource owner. Since such applications reside within the user-
agent, they can make seamless use of the user-agent capabilities agent, they can make seamless use of the user-agent capabilities
when requesting authorization. when requesting authorization.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
2.3. Client Identifier 2.3. Client Identifier
The authorization server issues the registered client a client The authorization server issues the registered client a client
identifier - a unique string representing the registration identifier - a unique string representing the registration
information provided by the client. The client identifier is not a information provided by the client. The client identifier is not a
secret, it is exposed to the resource owner, and cannot be used alone secret, it is exposed to the resource owner, and cannot be used alone
for client authentication. for client authentication.
2.4. Client Authentication 2.4. Client Authentication
If the client type is private, the client and authorization server If the client type is confidential, the client and authorization
establish a client authentication method suitable for the security server establish a client authentication method suitable for the
requirements of the authorization server. The authorization server security requirements of the authorization server. The authorization
MAY accept any form of client authentication meeting its security server MAY accept any form of client authentication meeting its
requirements. security requirements.
Private clients are typically issued (or establish) a set of client Confidential clients are typically issued (or establish) a set of
credentials used for authenticating with the authorization server client credentials used for authenticating with the authorization
(e.g. password, public/private key pair). server (e.g. password, public/private key pair).
The authorization server SHOULD NOT make assumptions about the client The authorization server SHOULD NOT make assumptions about the client
type or accept the type information provided without establishing type or accept the type information provided without establishing
trust with the client or its developer. The authorization server MAY trust with the client or its developer. The authorization server MAY
establish a client authentication method with public clients. establish a client authentication method with public clients.
However, the authorization server MUST NOT rely on public client However, the authorization server MUST NOT rely on public client
authentication for the purpose of identifying the client. authentication for the purpose of identifying the client.
The client MUST NOT use more than one authentication method in each The client MUST NOT use more than one authentication method in each
request. request.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
the client. The authorization server redirects the user-agent to the the client. The authorization server redirects the user-agent to the
client's redirection endpoint previously established with the client's redirection endpoint previously established with the
authorization server during the client registration process or when authorization server during the client registration process or when
initiating the authorization request. initiating the authorization request.
The redirection endpoint URI MUST be an absolute URI as defined by The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] section 4.3, MAY include a query component which MUST be [RFC3986] section 4.3, MAY include a query component which MUST be
retained by the authorization server when adding additional query retained by the authorization server when adding additional query
parameters, and MUST NOT include a fragment component. parameters, and MUST NOT include a fragment component.
3.1.2.1. Endpoint Confidentiality 3.1.2.1. Endpoint Request Confidentiality
If a redirection request will result in the transmission of an If a redirection request will result in the transmission of an
authorization code or access token over an open network (between the authorization code or access token over an open network (between the
resource owner's user-agent and the client), the client SHOULD resource owner's user-agent and the client), the client SHOULD
require the use of a transport-layer security mechanism. require the use of a transport-layer security mechanism.
Lack of transport-layer security can have a severe impact on the Lack of transport-layer security can have a severe impact on the
security of the client and the protected resources it is authorized security of the client and the protected resources it is authorized
to access. The use of transport-layer security is particularly to access. The use of transport-layer security is particularly
critical when the authorization process is used as a form of critical when the authorization process is used as a form of
skipping to change at page 18, line 26 skipping to change at page 18, line 26
from being used as an open redirector. from being used as an open redirector.
3.1.2.5. Endpoint Content 3.1.2.5. Endpoint Content
The redirection request to the client's endpoint typically results in The redirection request to the client's endpoint typically results in
an HTML document response, processed by the user-agent. If the HTML an HTML document response, processed by the user-agent. If the HTML
response is served directly as the result of the redirection request, response is served directly as the result of the redirection request,
any script included in the HTML document will execute with full any script included in the HTML document will execute with full
access to the redirection URI and the credentials it contains. access to the redirection URI and the credentials it contains.
The client SHOULD NOT include any third-party scripts in the
redirection endpoint response. Instead, it should extract the
credentials from the URI and redirect the user-agent again to another
endpoint without the credentials in the URI.
The client MUST NOT include any untrusted third-party scripts in the The client MUST NOT include any untrusted third-party scripts in the
redirection endpoint response (e.g. third-party analytics, social redirection endpoint response (e.g. third-party analytics, social
plug-ins, ad networks) without first ensuring that its own scripts plug-ins, ad networks) without first ensuring that its own scripts
used to extract and remove the credentials from the URI will execute used to extract and remove the credentials from the URI will execute
first. first.
The client SHOULD NOT include any third-party scripts in the
redirection endpoint response. Instead, it should extract the
credentials from the URI and redirect the user-agent again to another
endpoint without the credentials in the URI.
3.2. Token Endpoint 3.2. Token Endpoint
The token endpoint is used by the client to obtain an access token by The token endpoint is used by the client to obtain an access token by
presenting its authorization grant or refresh token. The token presenting its authorization grant or refresh token. The token
endpoint is used with every authorization grant except for the endpoint is used with every authorization grant except for the
implicit grant type (since an access token is issued directly). implicit grant type (since an access token is issued directly).
The means through which the client obtains the location of the token The means through which the client obtains the location of the token
endpoint are beyond the scope of this specification but is typically endpoint are beyond the scope of this specification but is typically
provided in the service documentation. The endpoint URI MAY include provided in the service documentation. The endpoint URI MAY include
skipping to change at page 19, line 20 skipping to change at page 19, line 20
The client MUST use the HTTP "POST" method when making access token The client MUST use the HTTP "POST" method when making access token
requests. requests.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server SHOULD ignore omitted from the request. The authorization server SHOULD ignore
unrecognized request parameters. Request and response parameters unrecognized request parameters. Request and response parameters
MUST NOT be included more than once. MUST NOT be included more than once.
3.2.1. Client Authentication 3.2.1. Client Authentication
Private clients, clients issued client credentials, or clients Confidential clients, clients issued client credentials, or clients
assigned other authentication requirements, MUST authenticate with assigned other authentication requirements, MUST authenticate with
the authorization server as described in Section 2.4 when making the authorization server as described in Section 2.4 when making
requests to the token endpoint. Client authentication is used for: requests to the token endpoint. Client authentication is used for:
o Enforcing the binding of refresh tokens and authorization codes to o Enforcing the binding of refresh tokens and authorization codes to
the client they are issued. Client authentication is critical the client they are issued. Client authentication is critical
when an authorization code is transmitted to the redirection when an authorization code is transmitted to the redirection
endpoint over an insecure channel, or when the redirection URI has endpoint over an insecure channel, or when the redirection URI has
not been registered in full. not been registered in full.
o Recovery from a compromised client by disabling the client or o Recovery from a compromised client by disabling the client or
skipping to change at page 20, line 10 skipping to change at page 20, line 10
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner. The authorization is expressed in the form of an resource owner. The authorization is expressed in the form of an
authorization grant which the client uses to request the access authorization grant which the client uses to request the access
token. OAuth defines four grant types: authorization code, implicit, token. OAuth defines four grant types: authorization code, implicit,
resource owner password credentials, and client credentials. It also resource owner password credentials, and client credentials. It also
provides an extension mechanism for defining additional grant types. provides an extension mechanism for defining additional grant types.
4.1. Authorization Code 4.1. Authorization Code
The authorization code grant type is used to obtain both access The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for private clients. As a tokens and refresh tokens and is optimized for confidential clients.
redirection-based flow, the client must be capable of interacting As a redirection-based flow, the client must be capable of
with the resource owner's user-agent (typically a web browser) and interacting with the resource owner's user-agent (typically a web
capable of receiving incoming requests (via redirection) from the browser) and capable of receiving incoming requests (via redirection)
authorization server. from the authorization server.
+----------+ +----------+
| resource | | resource |
| owner | | owner |
| | | |
+----------+ +----------+
^ ^
| |
(B) (B)
+----|-----+ Client Identifier +---------------+ +----|-----+ Client Identifier +---------------+
skipping to change at page 25, line 13 skipping to change at page 25, line 13
REQUIRED. Value MUST be set to "authorization_code". REQUIRED. Value MUST be set to "authorization_code".
code code
REQUIRED. The authorization code received from the REQUIRED. The authorization code received from the
authorization server. authorization server.
redirect_uri redirect_uri
REQUIRED, if the "redirect_uri" parameter was included in the REQUIRED, if the "redirect_uri" parameter was included in the
authorization request described in Section 4.1.1, and their authorization request described in Section 4.1.1, and their
values MUST be identical. values MUST be identical.
If the client type is private or was issued client credentials (or If the client type is confidential or was issued client credentials
assigned other authentication requirements), the client MUST (or assigned other authentication requirements), the client MUST
authenticate with the authorization server as described in authenticate with the authorization server as described in
Section 3.2.1. Section 3.2.1.
For example, the client makes the following HTTP using transport- For example, the client makes the following HTTP using transport-
layer security (extra line breaks are for display purposes only): layer security (extra 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 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST: The authorization server MUST:
o require client authentication for private clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client issued client credentials (or with other authentication
requirements), requirements),
o authenticate the client if client authentication is included and o authenticate the client if client authentication is included and
ensure the authorization code was issued to the authenticated ensure the authorization code was issued to the authenticated
client, client,
o verify that the authorization code is valid, and o verify that the authorization code is valid, and
o ensure that the "redirect_uri" parameter is present if the o ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization "redirect_uri" parameter was included in the initial authorization
request described in Section 4.1.1, and that their values are request described in Section 4.1.1, and that their values are
identical. identical.
skipping to change at page 33, line 26 skipping to change at page 33, line 26
password password
REQUIRED. The resource owner password, encoded as UTF-8. REQUIRED. The resource owner password, encoded as UTF-8.
scope scope
OPTIONAL. The scope of the access request expressed as a list OPTIONAL. The scope of the access request expressed as a list
of space-delimited, case sensitive strings. The value is of space-delimited, case sensitive strings. The value 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.
If the client type is private or was issued client credentials (or If the client type is confidential or was issued client credentials
assigned other authentication requirements), the client MUST (or assigned other authentication requirements), the client MUST
authenticate with the authorization server as described in authenticate with the authorization server as described in
Section 3.2.1. Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
transport-layer security (extra line breaks are for display purposes transport-layer security (extra line breaks are for display purposes
only): only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=password&username=johndoe&password=A3ddj3w grant_type=password&username=johndoe&password=A3ddj3w
The authorization server MUST: The authorization server MUST:
o require client authentication for private clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client issued client credentials (or with other authentication
requirements), requirements),
o authenticate the client if client authentication is included, and o authenticate the client if client authentication is included, and
o validate the resource owner password credentials. o validate the resource owner password credentials.
Since this access token request utilizes the resource owner's Since this access token request utilizes the resource owner's
password, the authorization server MUST protect the endpoint against password, the authorization server MUST protect the endpoint against
brute force attacks. brute force attacks.
4.3.3. Access Token Response 4.3.3. Access Token Response
skipping to change at page 34, line 42 skipping to change at page 34, line 42
4.4. Client Credentials 4.4. Client Credentials
The client can request an access token using only its client The client can request an access token using only its client
credentials (or other supported means of authentication) when the credentials (or other supported means of authentication) when the
client is requesting access to the protected resources under its client is requesting access to the protected resources under its
control, or those of another resource owner which has been previously control, or those of another resource owner which has been previously
arranged with the authorization server (the method of which is beyond arranged with the authorization server (the method of which is beyond
the scope of this specification). the scope of this specification).
The client credentials grant type MUST only be used by private The client credentials grant type MUST only be used by confidential
clients. clients.
+---------+ +---------------+ +---------+ +---------------+
| | | | | | | |
| |>--(A)- Client Authentication --->| Authorization | | |>--(A)- Client Authentication --->| Authorization |
| Client | | Server | | Client | | Server |
| |<--(B)---- Access Token ---------<| | | |<--(B)---- Access Token ---------<| |
| | | | | | | |
+---------+ +---------------+ +---------+ +---------------+
skipping to change at page 41, line 7 skipping to change at page 41, line 7
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. The requested scope MUST be equal or lesser requested scope. The requested scope MUST be equal or lesser
than the scope originally granted by the resource owner, and if than the scope originally granted by the resource owner, and if
omitted is treated as equal to the scope originally granted by omitted is treated as equal to the scope originally granted by
the resource owner. the resource owner.
Because refresh tokens are typically long-lasting credentials used to Because refresh tokens are typically long-lasting credentials used to
request additional access tokens, the refresh token is bound to the request additional access tokens, the refresh token is bound to the
client it was issued. If the client type is private or was issued client it was issued. If the client type is confidential or was
client credentials (or assigned other authentication requirements), issued client credentials (or assigned other authentication
the client MUST authenticate with the authorization server as requirements), the client MUST authenticate with the authorization
described in Section 3.2.1. server as described in Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
transport-layer security (extra line breaks are for display purposes transport-layer security (extra line breaks are for display purposes
only): only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
The authorization server MUST: The authorization server MUST:
o require client authentication for private clients or for any o require client authentication for confidential clients or for any
client issued client credentials (or with other authentication client issued client credentials (or with other authentication
requirements), requirements),
o authenticate the client if client authentication is included and o authenticate the client if client authentication is included and
ensure the refresh token was issued to the authenticated client, ensure the refresh token was issued to the authenticated client,
o validate the refresh token, and o validate the refresh token, and
If valid and authorized, the authorization server issues an access If valid and authorized, the authorization server issues an access
token as described in Section 5.1. If the request failed token as described in Section 5.1. If the request failed
verification or is invalid, the authorization server returns an error verification or is invalid, the authorization server returns an error
response as described in Section 5.2. response as described in Section 5.2.
skipping to change at page 51, line 33 skipping to change at page 51, line 33
using an access token associated with the attacker's account rather using an access token associated with the attacker's account rather
than the victim's. Depending on the nature of the client and the than the victim's. Depending on the nature of the client and the
protected resources, this can have undesirable and damaging effects. protected resources, this can have undesirable and damaging effects.
It is strongly RECOMMENDED that the client includes the "state" It is strongly RECOMMENDED that the client includes the "state"
request parameter with authorization requests to the authorization request parameter with authorization requests to the authorization
server. The "state" request parameter MUST contain a non-guessable server. The "state" request parameter MUST contain a non-guessable
value, and the client MUST keep it in a location accessible only by value, and the client MUST keep it in a location accessible only by
the client or the user-agent (i.e., protected by same-origin policy). the client or the user-agent (i.e., protected by same-origin policy).
For example, using a DOM variable (protected by JavaScript or other For example, using a DOM variable, HTTP cookie, or HTML5 client-side
DOM-binding language's enforcement of SOP [[ add reference ]]), HTTP storage. The authorization server includes the value of the "state"
cookie, or HTML5 client-side storage. The authorization server parameter when redirecting the user-agent back to the client which
includes the value of the "state" parameter when redirecting the MUST then ensure the received value matches the stored value.
user-agent back to the client which MUST then ensure the received
value matches the stored value.
10.13. Clickjacking 10.13. Clickjacking
[[ Rework to use specification terminology ]] In a clickjacking attack, an attacker registers a legitimate client
and then constructs a malicious site in which it loads the
Clickjacking is the process of tricking end-users into revealing authorization server's authorization endpoint web page in a
confidential information or taking control of their device while transparent iframe overlaid on top of a set of dummy buttons which
clicking on seemingly innocuous web pages. In more detail, a are carefully constructed to be placed directly under important
malicious site loads the target site in a transparent iframe overlaid buttons on the authorization page. When an end-user clicks a
on top of a set of dummy buttons which are carefully constructed to misleading visible button, the end-user is actually clicking an
be placed directly under important buttons on the target site. When invisible button on the authorization page (such as an "Authorize"
a user clicks a visible button, they are actually clicking a button button). This allows an attacker to trick a resource owner into
(such as an "Authorize" button) on the hidden page. granting its client access without their knowledge.
To prevent clickjacking (and phishing attacks), native applications To prevent this form of attack, native applications SHOULD use
SHOULD use external browsers instead of embedding browsers in an external browsers instead of embedding browsers in an iframe when
iframe when requesting end-user authorization. For newer browsers, requesting end-user authorization. For most newer browsers,
avoidance of iframes can be enforced by the authorization server avoidance of iframes can be enforced by the authorization server
using the "x-frame-options" header [[ Add reference ]]. This header using the (non-standard) "x-frame-options" header. This header can
can have two values, "deny" and "sameorigin", which will block any have two values, "deny" and "sameorigin", which will block any
framing or framing by sites with a different origin, respectively. framing, or framing by sites with a different origin, respectively.
For older browsers, javascript framebusting techniques can be used For older browsers, javascript framebusting techniques can be used
but may not be effective in all browsers. but may not be effective in all browsers.
10.14. Code Injection and Input Validation 10.14. Code Injection and Input Validation
A code injection attack occurs when an input or otherwise external A code injection attack occurs when an input or otherwise external
variable is used by an application in which that input can cause variable is used by an application in which that input can cause
modification of the application logic when used unsanitized. This modification of the application logic when used unsanitized. This
may allow an attacker to gain access to the application device or its may allow an attacker to gain access to the application device or its
data, cause denial of service, or a wide range of malicious side- data, cause denial of service, or a wide range of malicious side-
skipping to change at page 61, line 41 skipping to change at page 61, line 41
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
13.2. Informative References 13.2. Informative References
[I-D.draft-hardt-oauth-01] [I-D.draft-hardt-oauth-01]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
Web Resource Authorization Profiles", January 2010. Web Resource Authorization Profiles", January 2010.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Mortimore, C., "SAML 2.0 Bearer Assertion Grant Type
Grant Type Profile for OAuth 2.0", Profile for OAuth 2.0", draft-ietf-oauth-saml2-bearer-04
draft-ietf-oauth-saml2-bearer-03 (work in progress), (work in progress), May 2011.
February 2011.
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-06
(work in progress), March 2011. (work in progress), June 2011.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP
Authentication: MAC Access Authentication", Authentication: MAC Access Authentication",
draft-ietf-oauth-v2-http-mac-00 (work in progress), draft-ietf-oauth-v2-http-mac-00 (work in progress),
May 2011. May 2011.
[I-D.ietf-oauth-v2-threatmodel] [I-D.ietf-oauth-v2-threatmodel]
Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", Threat Model and Security Considerations",
 End of changes. 23 change blocks. 
66 lines changed or deleted 63 lines changed or added

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