diff options
Diffstat (limited to 'doc/specs')
| -rw-r--r-- | doc/specs/draft-ietf-oauth-v2-bearer-05.txt | 952 |
1 files changed, 952 insertions, 0 deletions
diff --git a/doc/specs/draft-ietf-oauth-v2-bearer-05.txt b/doc/specs/draft-ietf-oauth-v2-bearer-05.txt new file mode 100644 index 0000000..a446893 --- /dev/null +++ b/doc/specs/draft-ietf-oauth-v2-bearer-05.txt @@ -0,0 +1,952 @@ + + + +Network Working Group M. Jones +Internet-Draft Microsoft +Intended status: Standards Track D. Hardt +Expires: November 22, 2011 independent + D. Recordon + Facebook + May 21, 2011 + + + The OAuth 2.0 Protocol: Bearer Tokens + draft-ietf-oauth-v2-bearer-05 + +Abstract + + This specification describes how to use bearer tokens when accessing + OAuth 2.0 protected resources. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on November 22, 2011. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Jones, et al. Expires November 22, 2011 [Page 1] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Authenticated Requests . . . . . . . . . . . . . . . . . . . . 4 + 2.1. The Authorization Request Header Field . . . . . . . . . . 5 + 2.2. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 5 + 2.3. URI Query Parameter . . . . . . . . . . . . . . . . . . . 6 + 2.4. The WWW-Authenticate Response Header Field . . . . . . . . 7 + 2.4.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 8 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 3.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Summary of Recommendations . . . . . . . . . . . . . . . . 11 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. OAuth Access Token Type Registration . . . . . . . . . . . 11 + 4.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 12 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 + Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + + + + +Jones, et al. Expires November 22, 2011 [Page 2] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + +1. Introduction + + OAuth enables clients to access protected resources by obtaining an + access token, which is defined in [I-D.ietf-oauth-v2] as "a string + representing an access authorization issued to the client", rather + than using the resource owner's credentials. + + Tokens are issued to clients by an authorization server with the + approval of the resource owner. The client uses the access token to + access the protected resources hosted by the resource server. This + specification describes how to make protected resource requests when + the OAuth access token is a bearer token. + + This specification defines the use of bearer tokens with OAuth over + HTTP [RFC2616] using TLS [RFC5246]. Other specifications may extend + it for use with other transport protocols. + +1.1. 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], which is based upon the Augmented + Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the + following rules are included from [RFC2617]: auth-param and realm; + from [RFC3986]: URI-Reference; and from + [I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string. + + Unless otherwise noted, all the protocol parameter names and values + are case sensitive. + +1.2. Terminology + + Bearer Token + A security token with the property that any party in possession of + the token (a "bearer") can use the token in any way that any other + party in possession of it can. Using a bearer token does not + require a bearer to prove possession of cryptographic key material + (proof-of-possession). + + All other terms are as defined in [I-D.ietf-oauth-v2]. + +1.3. Overview + + OAuth provides a method for clients to access a protected resource on + behalf of a resource owner. Before a client can access a protected + + + +Jones, et al. Expires November 22, 2011 [Page 3] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + resource, it must first obtain authorization (access grant) from the + resource owner and then exchange the access grant for an access token + (representing the grant's scope, duration, and other attributes). + The client accesses the protected resource by presenting the access + token to the resource server. + + The access token provides an abstraction layer, replacing different + authorization constructs (e.g. username and password, assertion) for + a single token understood by the resource server. This abstraction + enables issuing access tokens valid for a short time period, as well + as removing the resource server's need to understand a wide range of + authentication schemes. + + +--------+ +---------------+ + | |--(A)- Authorization Request ->| Resource | + | | | Owner | + | |<-(B)----- Access Grant -------| | + | | +---------------+ + | | + | | Access Grant & +---------------+ + | |--(C)--- Client Credentials -->| Authorization | + | Client | | Server | + | |<-(D)----- Access Token -------| | + | | +---------------+ + | | + | | +---------------+ + | |--(E)----- Access Token ------>| Resource | + | | | Server | + | |<-(F)--- Protected Resource ---| | + +--------+ +---------------+ + + Figure 1: Abstract Protocol Flow + + The abstract flow illustrated in Figure 1 describes the overall OAuth + 2.0 protocol architecture. The following steps are specified within + this document: + + E) The client makes a protected resource request to the resource + server by presenting the access token. + + F) The resource server validates the access token, and if valid, + serves the request. + + +2. Authenticated Requests + + Clients SHOULD make authenticated requests with a bearer token using + the "Authorization" request header field defined by [RFC2617]. + + + +Jones, et al. Expires November 22, 2011 [Page 4] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + Resource servers MUST accept authenticated requests using the + "Bearer" HTTP authorization scheme as described in Section 2.1, and + MAY support additional methods. + + Alternatively, clients MAY transmit the access token in the HTTP body + when using the "application/x-www-form-urlencoded" content type as + described in Section 2.2; or clients MAY transmit the access token in + the HTTP request URI in the query component as described in + Section 2.3. Resource servers MAY support these alternative methods. + + Clients SHOULD NOT use the request body or URI unless the + "Authorization" request header field is not available, and MUST NOT + use more than one method to transmit the token in each request. + Because of the Security Considerations (Section 3) associated with + the URI method, it SHOULD NOT be used unless no other method is + feasible. + +2.1. The Authorization Request Header Field + + The "Authorization" request header field is used by clients to make + authenticated requests with bearer tokens. The client uses the + "Bearer" authentication scheme to transmit the access token in the + request. + + For example: + + GET /resource HTTP/1.1 + Host: server.example.com + Authorization: Bearer vF9dft4qmT + + The "Authorization" header field uses the framework defined by + [RFC2617] as follows: + + credentials = "Bearer" RWS access-token + access-token = 1*( quoted-char / <"> ) + + quoted-char = ALPHA / DIGIT / + "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / + "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / + ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / + "{" / "|" / "}" / "~" / "\" / "," / ";" + +2.2. Form-Encoded Body Parameter + + When including the access token in the HTTP request entity-body, the + client adds the access token to the request body using the + "bearer_token" parameter. The client MUST NOT use this method unless + the following conditions are met: + + + +Jones, et al. Expires November 22, 2011 [Page 5] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + o The HTTP request entity-body is single-part. + + o The entity-body follows the encoding requirements of the + "application/x-www-form-urlencoded" content-type as defined by + [W3C.REC-html401-19991224]. + + o The HTTP request entity-header includes the "Content-Type" header + field set to "application/x-www-form-urlencoded". + + o The HTTP request method is one for which a body is permitted to be + present in the request. In particular, this means that the "GET" + method MUST NOT be used. + + The entity-body can include other request-specific parameters, in + which case, the "bearer_token" parameter MUST be properly separated + from the request-specific parameters by an "&" character (ASCII code + 38). + + For example, the client makes the following HTTP request using + transport-layer security: + + POST /resource HTTP/1.1 + Host: server.example.com + Content-Type: application/x-www-form-urlencoded + + bearer_token=vF9dft4qmT + + The "application/x-www-form-urlencoded" method SHOULD NOT be used + except in application contexts where participating browsers do not + have access to the "Authorization" request header field. + +2.3. URI Query Parameter + + When including the access token in the HTTP request URI, the client + adds the access token to the request URI query component as defined + by [RFC3986] using the "bearer_token" parameter. + + For example, the client makes the following HTTP request using + transport-layer security: + + GET /resource?bearer_token=vF9dft4qmT HTTP/1.1 + Host: server.example.com + + The HTTP request URI query can include other request-specific + parameters, in which case, the "bearer_token" parameter MUST be + properly separated from the request-specific parameters by an "&" + character (ASCII code 38). + + + + +Jones, et al. Expires November 22, 2011 [Page 6] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + For example: + + http://example.com/resource?x=y&bearer_token=vF9dft4qmT + + Because of the Security Considerations (Section 3) associated with + the URI method, it SHOULD NOT be used unless no other method is + feasible. + +2.4. The WWW-Authenticate Response Header Field + + If the protected resource request does not include authentication + credentials or contains an invalid access token, the resource server + MUST include the HTTP "WWW-Authenticate" response header field; it + MAY include it in response to other conditions as well. The + "WWW-Authenticate" header field uses the framework defined by + [RFC2617] as follows: + + challenge = "Bearer" [ RWS 1#param ] + + param = realm / scope / + error / error-desc / error-uri / + auth-param + + scope = "scope" "=" <"> scope-v *( SP scope-v ) <"> + scope-v = 1*quoted-char + + quoted-char = ALPHA / DIGIT / + "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / + "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / + ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / + "{" / "|" / "}" / "~" / "\" / "," / ";" + + error = "error" "=" quoted-string + error-desc = "error_description" "=" quoted-string + error-uri = "error_uri" "=" <"> URI-reference <"> + + The "scope" attribute is a space-delimited list of scope values + indicating the required scope of the access token for accessing the + requested resource. The "scope" attribute MUST NOT appear more than + once. + + If the protected resource request included an access token and failed + authentication, the resource server SHOULD include the "error" + attribute to provide the client with the reason why the access + request was declined. The parameter value is described in + Section 2.4.1. In addition, the resource server MAY include the + "error_description" attribute to provide a human-readable + explanation, and the "error_uri" attribute with an absolute URI + + + +Jones, et al. Expires November 22, 2011 [Page 7] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + identifying a human-readable web page explaining the error. The + "error", "error_description", and "error_uri" attribute MUST NOT + appear more than once. [[ add language and encoding information to + error_description if the core specification does ]] + + For example, in response to a protected resource request without + authentication: + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer realm="example" + + And in response to a protected resource request with an + authentication attempt using an expired access token: + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer realm="example" + error="invalid_token", + error_description="The access token expired" + +2.4.1. Error Codes + + When a request fails, the resource server responds using the + appropriate HTTP status code (typically, 400, 401, or 403), and + includes one of the following error codes in the response: + + invalid_request + The request is missing a required parameter, includes an + unsupported parameter or parameter value, repeats the same + parameter, uses more than one method for including an access + token, or is otherwise malformed. The resource server SHOULD + respond with the HTTP 401 (Unauthorized) status code. + + invalid_token + The access token provided is expired, revoked, malformed, or + invalid for other reasons. The resource SHOULD respond with + the HTTP 401 (Unauthorized) status code. The client MAY + request a new access token and retry the protected resource + request. + + insufficient_scope + The request requires higher privileges than provided by the + access token. The resource server SHOULD respond with the HTTP + 403 (Forbidden) status code and MAY include the "scope" + attribute with the scope necessary to access the protected + resource. + + If the request lacks any authentication information (i.e. the client + was unaware authentication is necessary or attempted using an + + + +Jones, et al. Expires November 22, 2011 [Page 8] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + unsupported authentication method), the resource server SHOULD NOT + include an error code or other error information. + + For example: + + HTTP/1.1 401 Unauthorized + WWW-Authenticate: Bearer realm="example" + + +3. Security Considerations + + This section describes the relevant security threats regarding token + handling when using bearer tokens and describes how to mitigate these + threats. + +3.1. Security Threats + + The following list presents several common threats against protocols + utilizing some form of tokens. This list of threats is based on NIST + Special Publication 800-63 [NIST800-63]. Since this document builds + on the OAuth 2.0 specification, we exclude a discussion of threats + that are described there or in related documents. + + Token manufacture/modification: An attacker may generate a bogus + token or modify the token contents (such as the authentication or + attribute statements) of an existing token, causing the resource + server to grant inappropriate access to the client. For example, + an attacker may modify the token to extend the validity period; a + malicious client may modify the assertion to gain access to + information that they should not be able to view. + + Token disclosure: Tokens may contain authentication and attribute + statements that include sensitive information. + + Token redirect: An attacker uses the token generated for consumption + by resource server to obtain access to another resource server. + + Token replay: An attacker attempts to use a token that has already + been used with that resource server in the past. + +3.2. Threat Mitigation + + A large range of threats can be mitigated by protecting the contents + of the token by using a digital signature or a Message Authentication + Code (MAC). Alternatively, a bearer token can contain a reference to + authorization information, rather than encoding the information + directly. Such references MUST be infeasible for an attacker to + guess; using a reference may require an extra interaction between a + + + +Jones, et al. Expires November 22, 2011 [Page 9] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + server and the token issuer to resolve the reference to the + authorization information. + + This document does not specify the encoding or the contents of the + token; hence detailed recommendations for token integrity protection + are outside the scope of this document. We assume that the token + integrity protection is sufficient to prevent the token from being + modified. + + To deal with token redirect, it is important for the authorization + server to include the identity of the intended recipients (the + audience), typically a single resource server (or a list of resource + servers), in the token. Restricting the use of the token to a + specific scope is also recommended. + + To provide protection against token disclosure, confidentiality + protection is applied via TLS [RFC5246] with a ciphersuite that + offers confidentiality protection. This requires that the + communication interaction between the client and the authorization + server, as well as the interaction between the client and the + resource server, utilize confidentiality protection. Since TLS is + mandatory to implement and to use with this specification, it is the + preferred approach for preventing token disclosure via the + communication channel. For those cases where the client is prevented + from observing the contents of the token, token encryption has to be + applied in addition to the usage of TLS protection. + + To deal with token capture and replay, the following recommendations + are made: First, the lifetime of the token has to be limited by + putting a validity time field inside the protected part of the token. + Note that using short-lived (one hour or less) tokens significantly + reduces the impact of one of them being leaked. Second, + confidentiality protection of the exchanges between the client and + the authorization server and between the client and the resource + server MUST be applied, for instance, through the use of TLS + [RFC5246]. As a consequence, no eavesdropper along the communication + path is able to observe the token exchange. Consequently, such an + on-path adversary cannot replay the token. Furthermore, when + presenting the token to a resource server, the client MUST verify the + identity of that resource server, as per [RFC2818]. Note that the + client MUST validate the TLS certificate chain when making these + requests to protected resources. Presenting the token to an + unauthenticated and unauthorized resource server or failing to + validate the certificate chain will allow adversaries to steal the + token and gain unauthorized access to protected resources. + + + + + + +Jones, et al. Expires November 22, 2011 [Page 10] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + +3.3. Summary of Recommendations + + Safeguard bearer tokens Client implementations MUST ensure that + bearer tokens are not leaked to unintended parties, as they will + be able to use them to gain access to protected resources. This + is the primary security consideration when using bearer tokens and + underlies all the more specific recommendations that follow. + + Validate SSL certificate chains The client must validate the TLS + certificate chain when making requests to protected resources. + Failing to do so may enable DNS hijacking attacks to steal the + token and gain unintended access. + + Always use TLS (https) Clients MUST always use TLS [RFC5246] (https) + when making requests with bearer tokens. Failing to do so exposes + the token to numerous attacks that could give attackers unintended + access. + + Don't store bearer tokens in cookies Implementations MUST NOT store + bearer tokens within cookies that can be sent in the clear (which + is the default transmission mode for cookies). + + Issue short-lived bearer tokens Using short-lived (one hour or less) + bearer tokens can reduce the impact of one of them being leaked. + In particular, only short-lived bearer tokens should be issued to + clients that run within a web browser or other environments where + information leakage may occur. + + Issue scoped bearer tokens Issue bearer tokens that contain an + audience restriction, scoping their use to the intended relying + party or set of relying parties. + + Don't pass bearer tokens in page URLs Browsers, web servers, and + other software may not adequately secure URLs in the browser + history, web server logs, and other data structures. If bearer + tokens are passed in page URLs (typically as query string + parameters), attackers might be able to steal them from the + history data, logs, or other unsecured locations. Instead, pass + bearer tokens in HTTP message headers or message bodies for which + confidentiality measures are taken. + + +4. IANA Considerations + +4.1. OAuth Access Token Type Registration + + This specification registers the following access token type in the + OAuth Access Token Type Registry. + + + +Jones, et al. Expires November 22, 2011 [Page 11] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + +4.1.1. The "Bearer" OAuth Access Token Type + + Type name: + Bearer + + Additional Token Endpoint Response Parameters: + (none) + + HTTP Authentication Scheme(s): + Bearer + + Change controller: + IETF + + Specification document(s): + [[ this document ]] + + +5. References + +5.1. Normative References + + [I-D.ietf-httpbis-p1-messaging] + Fielding, R., Gettys, J., Mogul, J., Nielsen, H., + Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, + "HTTP/1.1, part 1: URIs, Connections, and Message + Parsing", draft-ietf-httpbis-p1-messaging-14 (work in + progress), April 2011. + + [I-D.ietf-oauth-v2] + Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth + 2.0 Authorization Protocol", draft-ietf-oauth-v2-16 (work + in progress), May 2011. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A., and L. Stewart, "HTTP + Authentication: Basic and Digest Access Authentication", + RFC 2617, June 1999. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + + + +Jones, et al. Expires November 22, 2011 [Page 12] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [W3C.REC-html401-19991224] + Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 + Specification", World Wide Web Consortium + Recommendation REC-html401-19991224, December 1999, + <http://www.w3.org/TR/1999/REC-html401-19991224>. + +5.2. Informative References + + [I-D.ietf-httpbis-p7-auth] + Fielding, R., Gettys, J., Mogul, J., Nielsen, H., + Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, + "HTTP/1.1, part 7: Authentication", + draft-ietf-httpbis-p7-auth-13 (work in progress), + March 2011. + + [NIST800-63] + Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., + and E. Nabbus, "NIST Special Publication 800-63-1, + INFORMATION SECURITY", December 2008. + + +Appendix A. Acknowledgements + + The following people contributed to preliminary versions of this + document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland + (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), + Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and + concepts within are a product of the OAuth community, the WRAP + community, and the OAuth Working Group. + + The OAuth Working Group has dozens of very active contributors who + proposed ideas and wording for this document, including: Michael + Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Culver, Bill + de hOra, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, + Evan Gilbert, Justin Hart, John Kemp, Eran Hammer-Lahav, Chasen Le + Hara, Michael B. Jones, Torsten Lodderstedt, Eve Maler, James Manger, + Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter + Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, + + + +Jones, et al. Expires November 22, 2011 [Page 13] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + Justin Smith, Jeremy Suriel, Christian Stuebner, Paul Tarjan, and + Franklin Tse. + + +Appendix B. Document History + + [[ to be removed by the RFC editor before publication as an RFC ]] + + -05 + + o Removed OAuth Errors Registry, per design team input. + + o Changed HTTP status code for "invalid_request" error code from + HTTP 400 (Bad Request) to HTTP 401 (Unauthorized) to match HTTP + usage [[ change pending working group consensus ]]. + + o Added missing quotation marks in error-uri definition. + + o Added note to add language and encoding information to + error_description if the core specification does. + + o Explicitly reference the Augmented Backus-Naur Form (ABNF) defined + in [RFC5234]. + + o Use auth-param instead of repeating its definition, which is ( + token "=" ( token / quoted-string ) ). + + o Clarify security considerations about including an audience + restriction in the token and include a recommendation to issue + scoped bearer tokens in the summary of recommendations. + + -04 + + o Edits responding to working group last call feedback on -03. + Specific edits enumerated below. + + o Added Bearer Token definition in Terminology section. + + o Changed parameter name "oauth_token" to "bearer_token". + + o Added realm parameter to "WWW-Authenticate" response to comply + with [RFC2617]. + + o Removed "[ RWS 1#auth-param ]" from "credentials" definition since + it did not comply with the ABNF in [I-D.ietf-httpbis-p7-auth]. + + o Removed restriction that the "bearer_token" (formerly + "oauth_token") parameter be the last parameter in the entity-body + + + +Jones, et al. Expires November 22, 2011 [Page 14] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + and the HTTP request URI query. + + o Do not require WWW-Authenticate Response in a reply to a malformed + request, as an HTTP 400 Bad Request response without a WWW- + Authenticate header is likely the right response in some cases of + malformed requests. + + o Removed OAuth Parameters registry extension. + + o Numerous editorial improvements suggested by working group + members. + + -03 + + o Restored the WWW-Authenticate response header functionality + deleted from the framework specification in draft 12 based upon + the specification text from draft 11. + + o Augmented the OAuth Parameters registry by adding two additional + parameter usage locations: "resource request" and "resource + response". + + o Registered the "oauth_token" OAuth parameter with usage location + "resource request". + + o Registered the "error" OAuth parameter. + + o Created the OAuth Error registry and registered errors. + + o Changed the "OAuth2" OAuth access token type name to "Bearer". + + -02 + + o Incorporated feedback received on draft 01. Most changes were to + the security considerations section. No normative changes were + made. Specific changes included: + + o Changed terminology from "token reuse" to "token capture and + replay". + + o Removed sentence "Encrypting the token contents is another + alternative" from the security considerations since it was + redundant and potentially confusing. + + o Corrected some references to "resource server" to be + "authorization server" in the security considerations. + + + + + +Jones, et al. Expires November 22, 2011 [Page 15] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + o Generalized security considerations language about obtaining + consent of the resource owner. + + o Broadened scope of security considerations description for + recommendation "Don't pass bearer tokens in page URLs". + + o Removed unused reference to OAuth 1.0. + + o Updated reference to framework specification and updated David + Recordon's e-mail address. + + o Removed security considerations text on authenticating clients. + + o Registered the "OAuth2" OAuth access token type and "oauth_token" + parameter. + + -01 + + o First public draft, which incorporates feedback received on -00 + including enhanced Security Considerations content. This version + is intended to accompany OAuth 2.0 draft 11. + + -00 + + o Initial draft based on preliminary version of OAuth 2.0 draft 11. + + +Authors' Addresses + + Michael B. Jones + Microsoft + + Email: mbj@microsoft.com + URI: http://self-issued.info/ + + + Dick Hardt + independent + + Email: dick.hardt@gmail.com + URI: http://dickhardt.org/ + + + + + + + + + + +Jones, et al. Expires November 22, 2011 [Page 16] + +Internet-Draft OAuth 2.0 Bearer Tokens May 2011 + + + David Recordon + Facebook + + Email: dr@fb.com + URI: http://www.davidrecordon.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jones, et al. Expires November 22, 2011 [Page 17] + |