Source: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-15.html
Timestamp: 2019-03-23 08:24:44
Document Index: 121608745

Matched Legal Cases: ['art 1', 'art 1', 'art 1', 'art 7', 'art 7', 'art 1', 'art 1', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 7', 'art 1', 'art 7', 'art 7', 'art 7', 'art 1', 'art 7', 'art 7', 'art 7', 'art 7']

Expires: June 20, 2012 independent
draft-ietf-oauth-v2-bearer-15
OAuth enables clients to access protected resources by obtaining an access token, which is defined in OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.) as "a string representing an access authorization issued to the client", rather than using the resource owner's credentials directly.
This specification defines the use of bearer tokens over HTTP/1.1 [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” October 2011.) using TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) to access protected resources. TLS is mandatory to implement and use with this specification; other specifications may extend this specification for use with other transport protocols. While designed for use with access tokens resulting from OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.) flows to access OAuth protected resources, this specification actually defines a general HTTP authorization method that can be used with bearer tokens from any source to access any resources protected by those bearer tokens.
This document uses the Augmented Backus-Naur Form (ABNF) notation of HTTP/1.1, Part 1 [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” October 2011.), which is based upon the Augmented Backus-Naur Form (ABNF) [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) notation. Additionally, the following rules are included from HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.): b64token, auth-param, and realm; from HTTP/1.1, Part 1 [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” October 2011.): quoted-string; and from Uniform Resource Identifier (URI) [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.): URI-Reference.
All other terms are as defined in OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” September 2011.).
When sending the access token in the Authorization request header field defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.), the client uses the Bearer authentication scheme to transmit the access token.
The Authorization header field uses the framework defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.) as follows:
The b64token syntax was chosen over the alternative #auth-param syntax also defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.) both for simplicity and for compatibility with existing implementations. If additional parameters are needed in the future, a different scheme would need to be defined.
The entity-body follows the encoding requirements of the application/x-www-form-urlencoded content-type as defined by HTML 4.01 [W3C.REC‑html401‑19991224] (Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.).
Because of the security weaknesses associated with the URI method (see Section 4 (Security Considerations)), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the Authorization request header field or the HTTP request entity-body. Resource servers MAY support this method.
If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, 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 HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.) as follows:
scope           = "scope" "=" quoted-string
error-uri       = "error_uri" "=" quoted-string
A realm attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.). The realm attribute MUST NOT appear more than once. The realm value is intended for programmatic use and is not meant to be displayed to end users.
The scope attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the scope value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. The scope attribute MUST NOT appear more than once. The scope value is intended for programmatic use and is not meant to be displayed to end users.
Producers of scope strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of error and error_description strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of error-uri strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing these values. Furthermore, error-uri strings MUST conform to the URI-Reference syntax. In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character.
To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) with a ciphersuite that provides confidentiality and integrity 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 and integrity 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 MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources.
To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact 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. 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 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125] (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.). 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.
This specification registers the following authentication scheme in the Authentication Scheme Registry defined in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.).
[I-D.ietf-httpbis-p1-messaging] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” draft-ietf-httpbis-p1-messaging-17 (work in progress), October 2011 (TXT).
[I-D.ietf-httpbis-p7-auth] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” draft-ietf-httpbis-p7-auth-17 (work in progress), October 2011 (TXT).
The OAuth Working Group has dozens of very active contributors who proposed ideas and wording for this document, including: Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, John Bradley, Brian Campbell, Leah Culver, Bill de hÓra, Brian Ellin, Igor Faynberg, Stephen Farrell, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Y. Goland, Thomas Hardjono, Justin Hart, Phil Hunt, John Kemp, Eran Hammer-Lahav, Chasen Le Hara, Barry Leiba, Michael B. Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian Stübner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane Weeden.
Clarified that the realm attribute MAY included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.).
Replaced sole remaining reference to [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) with HTTPbis [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” October 2011.) reference.
Use definitions from [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.) rather than [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.).
Update credentials definition to conform to [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.).
Registered "Bearer" Authentication Scheme in Authentication Scheme Registry defined by [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.).
Removed "[ RWS 1#auth-param ]" from credentials definition since it did not comply with the ABNF in [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” October 2011.).