idnits 2.17.1 draft-ietf-oauth-v2-bearer-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 31, 2011) is 4773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-13 == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-13 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-13 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track D. Hardt 5 Expires: October 2, 2011 independent 6 D. Recordon 7 Facebook 8 March 31, 2011 10 The OAuth 2.0 Protocol: Bearer Tokens 11 draft-ietf-oauth-v2-bearer-04 13 Abstract 15 This specification describes how to use bearer tokens when accessing 16 OAuth 2.0 protected resources. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 2, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Authenticated Requests . . . . . . . . . . . . . . . . . . . . 4 57 2.1. The Authorization Request Header Field . . . . . . . . . . 5 58 2.2. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 5 59 2.3. URI Query Parameter . . . . . . . . . . . . . . . . . . . 6 60 2.4. The WWW-Authenticate Response Header Field . . . . . . . . 7 61 2.4.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 8 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 3.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 9 65 3.3. Summary of Recommendations . . . . . . . . . . . . . . . . 11 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 4.1. OAuth Access Token Type Registration . . . . . . . . . . . 11 68 4.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 12 69 4.2. The OAuth Errors Registry . . . . . . . . . . . . . . . . 12 70 4.2.1. Registration Template . . . . . . . . . . . . . . . . 12 71 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 5.2. Informative References . . . . . . . . . . . . . . . . . . 15 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 76 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 OAuth enables clients to access protected resources by obtaining an 82 access token, which is defined in [I-D.ietf-oauth-v2] as "a string 83 representing an access authorization issued to the client", rather 84 than using the resource owner's credentials. 86 Tokens are issued to clients by an authorization server with the 87 approval of the resource owner. The client uses the access token to 88 access the protected resources hosted by the resource server. This 89 specification describes how to make protected resource requests when 90 the OAuth access token is a bearer token. 92 This specification defines the use of bearer tokens with OAuth over 93 HTTP [RFC2616] using TLS [RFC5246]. Other specifications may extend 94 it for use with other transport protocols. 96 1.1. Notational Conventions 98 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 99 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 100 document are to be interpreted as described in [RFC2119]. 102 This document uses the Augmented Backus-Naur Form (ABNF) notation of 103 [I-D.ietf-httpbis-p1-messaging]. Additionally, the following rules 104 are included from [RFC2617]: realm; from [RFC3986]: URI-Reference; 105 and from [I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string. 107 Unless otherwise noted, all the protocol parameter names and values 108 are case sensitive. 110 1.2. Terminology 112 Bearer Token 113 A security token with the property that any party in possession of 114 the token (a "bearer") can use the token in any way that any other 115 party in possession of it can. Using a bearer token does not 116 require a bearer to prove possession of cryptographic key material 117 (proof-of-possession). 119 All other terms are as defined in [I-D.ietf-oauth-v2]. 121 1.3. Overview 123 OAuth provides a method for clients to access a protected resource on 124 behalf of a resource owner. Before a client can access a protected 125 resource, it must first obtain authorization (access grant) from the 126 resource owner and then exchange the access grant for an access token 127 (representing the grant's scope, duration, and other attributes). 128 The client accesses the protected resource by presenting the access 129 token to the resource server. 131 The access token provides an abstraction layer, replacing different 132 authorization constructs (e.g. username and password, assertion) for 133 a single token understood by the resource server. This abstraction 134 enables issuing access tokens valid for a short time period, as well 135 as removing the resource server's need to understand a wide range of 136 authentication schemes. 138 +--------+ +---------------+ 139 | |--(A)- Authorization Request ->| Resource | 140 | | | Owner | 141 | |<-(B)----- Access Grant -------| | 142 | | +---------------+ 143 | | 144 | | Access Grant & +---------------+ 145 | |--(C)--- Client Credentials -->| Authorization | 146 | Client | | Server | 147 | |<-(D)----- Access Token -------| | 148 | | +---------------+ 149 | | 150 | | +---------------+ 151 | |--(E)----- Access Token ------>| Resource | 152 | | | Server | 153 | |<-(F)--- Protected Resource ---| | 154 +--------+ +---------------+ 156 Figure 1: Abstract Protocol Flow 158 The abstract flow illustrated in Figure 1 describes the overall OAuth 159 2.0 protocol architecture. The following steps are specified within 160 this document: 162 E) The client makes a protected resource request to the resource 163 server by presenting the access token. 165 F) The resource server validates the access token, and if valid, 166 serves the request. 168 2. Authenticated Requests 170 Clients SHOULD make authenticated requests with a bearer token using 171 the "Authorization" request header field defined by [RFC2617]. 172 Resource servers MUST accept authenticated requests using the 173 "Bearer" HTTP authorization scheme as described in Section 2.1, and 174 MAY support additional methods. 176 Alternatively, clients MAY transmit the access token in the HTTP body 177 when using the "application/x-www-form-urlencoded" content type as 178 described in Section 2.2; or clients MAY transmit the access token in 179 the HTTP request URI in the query component as described in 180 Section 2.3. Resource servers MAY support these alternative methods. 182 Clients SHOULD NOT use the request body or URI unless the 183 "Authorization" request header field is not available, and MUST NOT 184 use more than one method to transmit the token in each request. 185 Because of the Security Considerations (Section 3) associated with 186 the URI method, it SHOULD NOT be used unless no other method is 187 feasible. 189 2.1. The Authorization Request Header Field 191 The "Authorization" request header field is used by clients to make 192 authenticated requests with bearer tokens. The client uses the 193 "Bearer" authentication scheme to transmit the access token in the 194 request. 196 For example: 198 GET /resource HTTP/1.1 199 Host: server.example.com 200 Authorization: Bearer vF9dft4qmT 202 The "Authorization" header field uses the framework defined by 203 [RFC2617] as follows: 205 credentials = "Bearer" RWS access-token 206 access-token = 1*( quoted-char / <"> ) 208 quoted-char = "!" / "#" / "$" / "%" / "&" / "'" / "(" 209 / ")" / "*" / "+" / "-" / "." / "/" / DIGIT 210 / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA 211 / "[" / "]" / "^" / "_" / "`" / "{" / "|" 212 / "}" / "~" / "\" / "," / ";" 214 2.2. Form-Encoded Body Parameter 216 When including the access token in the HTTP request entity-body, the 217 client adds the access token to the request body using the 218 "bearer_token" parameter. The client MUST NOT use this method unless 219 the following conditions are met: 221 o The HTTP request entity-body is single-part. 223 o The entity-body follows the encoding requirements of the 224 "application/x-www-form-urlencoded" content-type as defined by 225 [W3C.REC-html401-19991224]. 227 o The HTTP request entity-header includes the "Content-Type" header 228 field set to "application/x-www-form-urlencoded". 230 o The HTTP request method is one for which a body is permitted to be 231 present in the request. In particular, this means that the "GET" 232 method MUST NOT be used. 234 The entity-body can include other request-specific parameters, in 235 which case, the "bearer_token" parameter MUST be properly separated 236 from the request-specific parameters by an "&" character (ASCII code 237 38). 239 For example, the client makes the following HTTP request using 240 transport-layer security: 242 POST /resource HTTP/1.1 243 Host: server.example.com 244 Content-Type: application/x-www-form-urlencoded 246 bearer_token=vF9dft4qmT 248 The "application/x-www-form-urlencoded" method SHOULD NOT be used 249 except in application contexts where participating browsers do not 250 have access to the "Authorization" request header field. 252 2.3. URI Query Parameter 254 When including the access token in the HTTP request URI, the client 255 adds the access token to the request URI query component as defined 256 by [RFC3986] using the "bearer_token" parameter. 258 For example, the client makes the following HTTP request using 259 transport-layer security: 261 GET /resource?bearer_token=vF9dft4qmT HTTP/1.1 262 Host: server.example.com 264 The HTTP request URI query can include other request-specific 265 parameters, in which case, the "bearer_token" parameter MUST be 266 properly separated from the request-specific parameters by an "&" 267 character (ASCII code 38). 269 For example: 271 http://example.com/resource?x=y&bearer_token=vF9dft4qmT 273 Because of the Security Considerations (Section 3) associated with 274 the URI method, it SHOULD NOT be used unless no other method is 275 feasible. 277 2.4. The WWW-Authenticate Response Header Field 279 If the protected resource request does not include authentication 280 credentials or contains an invalid access token, the resource server 281 MUST include the HTTP "WWW-Authenticate" response header field; it 282 MAY include it in response to other conditions as well. The 283 "WWW-Authenticate" header field uses the framework defined by 284 [RFC2617] as follows: 286 challenge = "Bearer" [ RWS 1#param ] 288 param = realm / scope / 289 error / error-desc / error-uri / 290 ( token "=" ( token / quoted-string ) ) 292 scope = "scope" "=" <"> scope-v *( SP scope-v ) <"> 293 scope-v = 1*quoted-char 295 quoted-char = ALPHA / DIGIT / 296 "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / 297 "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / 298 ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / 299 "{" / "|" / "}" / "~" / "\" / "," / ";" 301 error = "error" "=" quoted-string 302 error-desc = "error_description" "=" quoted-string 303 error-uri = "error_uri" = <"> URI-reference <"> 305 The "scope" attribute is a space-delimited list of scope values 306 indicating the required scope of the access token for accessing the 307 requested resource. The "scope" attribute MUST NOT appear more than 308 once. 310 If the protected resource request included an access token and failed 311 authentication, the resource server SHOULD include the "error" 312 attribute to provide the client with the reason why the access 313 request was declined. The parameter value is described in 314 Section 2.4.1. In addition, the resource server MAY include the 315 "error_description" attribute to provide a human-readable 316 explanation, and the "error_uri" attribute with an absolute URI 317 identifying a human-readable web page explaining the error. The 318 "error", "error_description", and "error_uri" attribute MUST NOT 319 appear more than once. 321 For example, in response to a protected resource request without 322 authentication: 324 HTTP/1.1 401 Unauthorized 325 WWW-Authenticate: Bearer realm="example" 327 And in response to a protected resource request with an 328 authentication attempt using an expired access token: 330 HTTP/1.1 401 Unauthorized 331 WWW-Authenticate: Bearer realm="example" 332 error="invalid_token", 333 error_description="The access token expired" 335 2.4.1. Error Codes 337 When a request fails, the resource server responds using the 338 appropriate HTTP status code (typically, 400, 401, or 403), and 339 includes one of the following error codes in the response: 341 invalid_request 342 The request is missing a required parameter, includes an 343 unsupported parameter or parameter value, repeats the same 344 parameter, uses more than one method for including an access 345 token, or is otherwise malformed. The resource server SHOULD 346 respond with the HTTP 400 (Bad Request) status code. 348 invalid_token 349 The access token provided is expired, revoked, malformed, or 350 invalid for other reasons. The resource SHOULD respond with 351 the HTTP 401 (Unauthorized) status code. The client MAY 352 request a new access token and retry the protected resource 353 request. 355 insufficient_scope 356 The request requires higher privileges than provided by the 357 access token. The resource server SHOULD respond with the HTTP 358 403 (Forbidden) status code and MAY include the "scope" 359 attribute with the scope necessary to access the protected 360 resource. 362 New errors MUST be separately registered in the OAuth Errors registry 363 as described by Section 4.2. 365 If the request lacks any authentication information (i.e. the client 366 was unaware authentication is necessary or attempted using an 367 unsupported authentication method), the resource server SHOULD NOT 368 include an error code or other error information. 370 For example: 372 HTTP/1.1 401 Unauthorized 373 WWW-Authenticate: Bearer realm="example" 375 3. Security Considerations 377 This section describes the relevant security threats regarding token 378 handling when using bearer tokens and describes how to mitigate these 379 threats. 381 3.1. Security Threats 383 The following list presents several common threats against protocols 384 utilizing some form of tokens. This list of threats is based on NIST 385 Special Publication 800-63 [NIST800-63]. Since this document builds 386 on the OAuth 2.0 specification, we exclude a discussion of threats 387 that are described there or in related documents. 389 Token manufacture/modification: An attacker may generate a bogus 390 token or modify the token contents (such as the authentication or 391 attribute statements) of an existing token, causing the resource 392 server to grant inappropriate access to the client. For example, 393 an attacker may modify the token to extend the validity period; a 394 malicious client may modify the assertion to gain access to 395 information that they should not be able to view. 397 Token disclosure: Tokens may contain authentication and attribute 398 statements that include sensitive information. 400 Token redirect: An attacker uses the token generated for consumption 401 by resource server to obtain access to another resource server. 403 Token replay: An attacker attempts to use a token that has already 404 been used with that resource server in the past. 406 3.2. Threat Mitigation 408 A large range of threats can be mitigated by protecting the contents 409 of the token by using a digital signature or a Message Authentication 410 Code (MAC). Alternatively, a bearer token can contain a reference to 411 authorization information, rather than encoding the information 412 directly. Such references MUST be infeasible for an attacker to 413 guess; using a reference may require an extra interaction between a 414 server and the token issuer to resolve the reference to the 415 authorization information. 417 This document does not specify the encoding or the contents of the 418 token; hence detailed recommendations for token integrity protection 419 are outside the scope of this document. We assume that the token 420 integrity protection is sufficient to prevent the token from being 421 modified. 423 To deal with token redirect, it is important for the authorization 424 server to include the identity of the intended recipients, namely a 425 single resource server (or a list of resource servers). Restricting 426 the use of the token to a specific scope is also recommended. 428 To provide protection against token disclosure, confidentiality 429 protection is applied via TLS [RFC5246] with a ciphersuite that 430 offers confidentiality protection. This requires that the 431 communication interaction between the client and the authorization 432 server, as well as the interaction between the client and the 433 resource server, utilize confidentiality protection. Since TLS is 434 mandatory to implement and to use with this specification, it is the 435 preferred approach for preventing token disclosure via the 436 communication channel. For those cases where the client is prevented 437 from observing the contents of the token, token encryption has to be 438 applied in addition to the usage of TLS protection. 440 To deal with token capture and replay, the following recommendations 441 are made: First, the lifetime of the token has to be limited by 442 putting a validity time field inside the protected part of the token. 443 Note that using short-lived (one hour or less) tokens significantly 444 reduces the impact of one of them being leaked. Second, 445 confidentiality protection of the exchanges between the client and 446 the authorization server and between the client and the resource 447 server MUST be applied, for instance, through the use of TLS 448 [RFC5246]. As a consequence, no eavesdropper along the communication 449 path is able to observe the token exchange. Consequently, such an 450 on-path adversary cannot replay the token. Furthermore, when 451 presenting the token to a resource server, the client MUST verify the 452 identity of that resource server, as per [RFC2818]. Note that the 453 client MUST validate the TLS certificate chain when making these 454 requests to protected resources. Presenting the token to an 455 unauthenticated and unauthorized resource server or failing to 456 validate the certificate chain will allow adversaries to steal the 457 token and gain unauthorized access to protected resources. 459 3.3. Summary of Recommendations 461 Safeguard bearer tokens Client implementations MUST ensure that 462 bearer tokens are not leaked to unintended parties, as they will 463 be able to use them to gain access to protected resources. This 464 is the primary security consideration when using bearer tokens and 465 underlies all the more specific recommendations that follow. 467 Validate SSL certificate chains The client must validate the TLS 468 certificate chain when making requests to protected resources. 469 Failing to do so may enable DNS hijacking attacks to steal the 470 token and gain unintended access. 472 Always use TLS (https) Clients MUST always use TLS [RFC5246] (https) 473 when making requests with bearer tokens. Failing to do so exposes 474 the token to numerous attacks that could give attackers unintended 475 access. 477 Don't store bearer tokens in cookies Implementations MUST NOT store 478 bearer tokens within cookies that can be sent in the clear (which 479 is the default transmission mode for cookies). 481 Issue short-lived bearer tokens Using short-lived (one hour or less) 482 bearer tokens can reduce the impact of one of them being leaked. 483 In particular, only short-lived bearer tokens should be issued to 484 clients that run within a web browser or other environments where 485 information leakage may occur. 487 Don't pass bearer tokens in page URLs Browsers, web servers, and 488 other software may not adequately secure URLs in the browser 489 history, web server logs, and other data structures. If bearer 490 tokens are passed in page URLs (typically as query string 491 parameters), attackers might be able to steal them from the 492 history data, logs, or other unsecured locations. Instead, pass 493 bearer tokens in HTTP message headers or message bodies for which 494 confidentiality measures are taken. 496 4. IANA Considerations 498 4.1. OAuth Access Token Type Registration 500 This specification registers the following access token type in the 501 OAuth Access Token Type Registry. 503 4.1.1. The "Bearer" OAuth Access Token Type 505 Type name: 506 Bearer 508 Additional Token Endpoint Response Parameters: 509 (none) 511 HTTP Authentication Scheme(s): 512 Bearer 514 Change controller: 515 IETF 517 Specification document(s): 518 [[ this document ]] 520 4.2. The OAuth Errors Registry 522 This specification establishes the OAuth Errors registry. 524 Additional errors for inclusion in the authorization endpoint 525 response, the token endpoint response, or the resource endpoint 526 response are registered on the advice of one or more Designated 527 Experts (appointed by the IESG or their delegate), with a 528 Specification Required (using terminology from [RFC5226]). However, 529 to allow for the allocation of values prior to publication, the 530 Designated Expert(s) may approve registration once they are satisfied 531 that such a specification will be published. 533 Registration requests should be sent to the [TBD]@ietf.org mailing 534 list for review and comment, with an appropriate subject (e.g., 535 "Request for error: example"). [[ Note to RFC-EDITOR: The name of the 536 mailing list should be determined in consultation with the IESG and 537 IANA. Suggested name: oauth-ext-review. ]] 539 Before a period of 14 days has passed, the Designated Expert(s) will 540 either approve or deny the registration request, communicating this 541 decision both to the review list and to IANA. Denials should include 542 an explanation and, if applicable, suggestions as to how to make the 543 request successful. Registration requests that are undetermined for 544 a period longer than 21 days can be brought to the IESG's attention 545 (using the iesg@iesg.org mailing list) for resolution. 547 4.2.1. Registration Template 548 Error name: 549 The name requested (e.g., "example"). 551 Error usage location: 552 The location(s) where the error can be used. The possible 553 locations are: authorization response, token response, resource 554 response. 556 Change controller: 557 For standards-track RFCs, state "IETF". For others, give the name 558 of the responsible party. Other details (e.g., postal address, 559 e-mail address, home page URI) may also be included. 561 Specification document(s): 562 Reference to document that specifies the error, preferably 563 including a URI that can be used to retrieve a copy of the 564 document. An indication of the relevant sections may also be 565 included, but is not required. 567 4.2.2. Initial Registry Contents 569 The OAuth Errors Registry's initial contents are: 571 o Error name: invalid_request 573 o Error usage location: resource response 575 o Change controller: IETF 577 o Specification document(s): [[ this document ]] 579 o Error name: invalid_token 581 o Error usage location: resource response 583 o Change controller: IETF 585 o Specification document(s): [[ this document ]] 587 o Error name: insufficient_scope 589 o Error usage location: resource response 591 o Change controller: IETF 593 o Specification document(s): [[ this document ]] 595 5. References 597 5.1. Normative References 599 [I-D.ietf-httpbis-p1-messaging] 600 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 601 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 602 "HTTP/1.1, part 1: URIs, Connections, and Message 603 Parsing", draft-ietf-httpbis-p1-messaging-13 (work in 604 progress), March 2011. 606 [I-D.ietf-oauth-v2] 607 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 608 2.0 Authorization Protocol", draft-ietf-oauth-v2-13 (work 609 in progress), February 2011. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, March 1997. 614 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 615 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 616 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 618 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 619 Leach, P., Luotonen, A., and L. Stewart, "HTTP 620 Authentication: Basic and Digest Access Authentication", 621 RFC 2617, June 1999. 623 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 625 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 626 Resource Identifier (URI): Generic Syntax", STD 66, 627 RFC 3986, January 2005. 629 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 630 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 631 May 2008. 633 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 634 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 636 [W3C.REC-html401-19991224] 637 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 638 Specification", World Wide Web Consortium 639 Recommendation REC-html401-19991224, December 1999, 640 . 642 5.2. Informative References 644 [I-D.ietf-httpbis-p7-auth] 645 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 646 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 647 "HTTP/1.1, part 7: Authentication", 648 draft-ietf-httpbis-p7-auth-13 (work in progress), 649 March 2011. 651 [NIST800-63] 652 Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 653 and E. Nabbus, "NIST Special Publication 800-63-1, 654 INFORMATION SECURITY", December 2008. 656 Appendix A. Acknowledgements 658 The following people contributed to preliminary versions of this 659 document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland 660 (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), 661 Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and 662 concepts within are a product of the OAuth community, the WRAP 663 community, and the OAuth Working Group. 665 The OAuth Working Group has dozens of very active contributors who 666 proposed ideas and wording for this document, including: Michael 667 Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah Culver, Bill 668 de hOra, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, 669 Evan Gilbert, Justin Hart, John Kemp, Eran Hammer-Lahav, Chasen Le 670 Hara, Michael B. Jones, Torsten Lodderstedt, Eve Maler, James Manger, 671 Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter 672 Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, 673 Justin Smith, Jeremy Suriel, Christian Stuebner, Paul Tarjan, and 674 Franklin Tse. 676 Appendix B. Document History 678 [[ to be removed by the RFC editor before publication as an RFC ]] 680 -04 682 o Edits responding to working group last call feedback on -03. 683 Specific edits enumerated below. 685 o Added Bearer Token definition in Terminology section. 687 o Changed parameter name "oauth_token" to "bearer_token". 689 o Added realm parameter to "WWW-Authenticate" response to comply 690 with [RFC2617]. 692 o Removed "[ RWS 1#auth-param ]" from "credentials" definition since 693 it did not comply with the ABNF in [I-D.ietf-httpbis-p7-auth]. 695 o Removed restriction that the "bearer_token" (formerly 696 "oauth_token") parameter be the last parameter in the entity-body 697 and the HTTP request URI query. 699 o Do not require WWW-Authenticate Response in a reply to a malformed 700 request, as an HTTP 400 Bad Request response without a WWW- 701 Authenticate header is likely the right response in some cases of 702 malformed requests. 704 o Removed OAuth Parameters registry extension. 706 o Numerous editorial improvements suggested by working group 707 members. 709 -03 711 o Restored the WWW-Authenticate response header functionality 712 deleted from the framework specification in draft 12 based upon 713 the specification text from draft 11. 715 o Augmented the OAuth Parameters registry by adding two additional 716 parameter usage locations: "resource request" and "resource 717 response". 719 o Registered the "oauth_token" OAuth parameter with usage location 720 "resource request". 722 o Registered the "error" OAuth parameter. 724 o Created the OAuth Error registry and registered errors. 726 o Changed the "OAuth2" OAuth access token type name to "Bearer". 728 -02 730 o Incorporated feedback received on draft 01. Most changes were to 731 the security considerations section. No normative changes were 732 made. Specific changes included: 734 o Changed terminology from "token reuse" to "token capture and 735 replay". 737 o Removed sentence "Encrypting the token contents is another 738 alternative" from the security considerations since it was 739 redundant and potentially confusing. 741 o Corrected some references to "resource server" to be 742 "authorization server" in the security considerations. 744 o Generalized security considerations language about obtaining 745 consent of the resource owner. 747 o Broadened scope of security considerations description for 748 recommendation "Don't pass bearer tokens in page URLs". 750 o Removed unused reference to OAuth 1.0. 752 o Updated reference to framework specification and updated David 753 Recordon's e-mail address. 755 o Removed security considerations text on authenticating clients. 757 o Registered the "OAuth2" OAuth access token type and "oauth_token" 758 parameter. 760 -01 762 o First public draft, which incorporates feedback received on -00 763 including enhanced Security Considerations content. This version 764 is intended to accompany OAuth 2.0 draft 11. 766 -00 768 o Initial draft based on preliminary version of OAuth 2.0 draft 11. 770 Authors' Addresses 772 Michael B. Jones 773 Microsoft 775 Email: mbj@microsoft.com 776 URI: http://self-issued.info/ 777 Dick Hardt 778 independent 780 Email: dick.hardt@gmail.com 781 URI: http://dickhardt.org/ 783 David Recordon 784 Facebook 786 Email: dr@fb.com 787 URI: http://www.davidrecordon.com/