idnits 2.17.1 draft-ietf-oauth-v2-14.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5849, but the abstract doesn't seem to mention this, which it should. 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 (April 6, 2011) is 4741 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) ** 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 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-hammer-oauth-v2-mac-token-02 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-03 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-v2-bearer-02 -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hammer-Lahav, Ed. 3 Internet-Draft Yahoo! 4 Obsoletes: 5849 (if approved) D. Recordon 5 Intended status: Standards Track Facebook 6 Expires: October 8, 2011 D. Hardt 7 Microsoft 8 April 6, 2011 10 The OAuth 2.0 Authorization Protocol 11 draft-ietf-oauth-v2-14 13 Abstract 15 The OAuth 2.0 authorization protocol enables granting third-party 16 applications limited access to HTTP service on behalf of an end-user 17 by orchestrating an approval interaction between the end-user and the 18 HTTP service. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 6 59 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 8 60 1.6. Document Structure . . . . . . . . . . . . . . . . . . . . 10 61 1.7. Notational Conventions . . . . . . . . . . . . . . . . . . 10 62 2. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 10 63 2.1. Authorization Endpoint . . . . . . . . . . . . . . . . . . 11 64 2.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 12 65 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 13 66 3.1. Client Password Authentication . . . . . . . . . . . . . . 14 67 3.2. Other Client Authentication Methods . . . . . . . . . . . 14 68 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 15 69 4.1. Authorization Code . . . . . . . . . . . . . . . . . . . . 15 70 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . . 21 71 4.3. Resource Owner Password Credentials . . . . . . . . . . . 27 72 4.4. Client Credentials . . . . . . . . . . . . . . . . . . . . 29 73 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 31 74 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 32 75 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 32 76 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . . 33 77 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 35 78 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 36 79 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . . 36 80 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 37 81 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 37 82 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . . 37 83 8.3. Defining New Authorization Grant Types . . . . . . . . . . 38 84 8.4. Defining Additional Error Codes . . . . . . . . . . . . . 38 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 87 10.1. The OAuth Access Token Type Registry . . . . . . . . . . . 39 88 10.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 40 89 10.3. The OAuth Extensions Error Registry . . . . . . . . . . . 43 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 91 Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 45 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 46 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 97 1. Introduction 99 In the traditional client-server authentication model, the client 100 accesses a protected resource on the server by authenticating with 101 the server using the resource owner's credentials. In order to 102 provide third-party applications access to protected resources, the 103 resource owner shares its credentials with the third-party. This 104 creates several problems and limitations: 106 o Third-party applications are required to store the resource- 107 owner's credentials for future use, typically a password in clear- 108 text. 109 o Servers are required to support password authentication, despite 110 the security weaknesses created by passwords. 111 o Third-party applications gain overly broad access to the resource- 112 owner's protected resources, leaving resource owners without any 113 ability to restrict duration or access to a limited subset of 114 resources. 115 o Resource owners cannot revoke access to an individual third-party 116 without revoking access to all third-parties, and must do so by 117 changing their password. 119 OAuth addresses these issues by introducing an authorization layer 120 and separating the role of the client from that of the resource 121 owner. In OAuth, the client requests access to resources controlled 122 by the resource owner and hosted by the resource server, and is 123 issued a different set of credentials than those of the resource 124 owner. 126 Instead of using the resource owner's credentials to access protected 127 resources, the client obtains an access token - a string denoting a 128 specific scope, duration, and other access attributes. Access tokens 129 are issued to third-party clients by an authorization server with the 130 approval of the resource owner. The client uses the access token to 131 access the protected resources hosted by the resource server. 133 For example, a web end-user (resource owner) can grant a printing 134 service (client) access to her protected photos stored at a photo 135 sharing service (resource server), without sharing her username and 136 password with the printing service. Instead, she authenticates 137 directly with a server trusted by the photo sharing service 138 (authorization server) which issues the printing service delegation- 139 specific credentials (access token). 141 This specification is designed for use with HTTP [RFC2616]. The use 142 of OAuth with any transport protocol other than HTTP is undefined. 144 1.1. Roles 146 OAuth includes four roles working together to grant and provide 147 access to protected resources - access restricted resources which 148 require authentication to access: 150 resource owner 151 An entity capable of granting access to a protected resource. 152 When the resource owner is a person, it is referred to as an end- 153 user. 154 resource server 155 The server hosting the protected resources, capable of accepting 156 and responding to protected resource requests using access tokens. 157 client 158 An application making protected resource requests on behalf of the 159 resource owner and with its authorization. 160 authorization server 161 The server issuing access tokens to the client after successfully 162 authenticating the resource owner and obtaining authorization. 164 The interaction between the authorization server and resource server 165 is beyond the scope of this specification. The authorization server 166 may be the same server as the resource server or a separate entity. 167 A single authorization server may issue access tokens accepted by 168 multiple resource servers. 170 1.2. Protocol Flow 172 When interacting with the authorization server, the client identifies 173 itself using a set of client credentials which include a client 174 identifier and other authentication attributes. The means through 175 which the client obtains its credentials are beyond the scope of this 176 specification, but typically involve registration with the 177 authorization server. 179 +--------+ +---------------+ 180 | |--(A)- Authorization Request ->| Resource | 181 | | | Owner | 182 | |<-(B)-- Authorization Grant ---| | 183 | | +---------------+ 184 | | 185 | | Authorization Grant & +---------------+ 186 | |--(C)--- Client Credentials -->| Authorization | 187 | Client | | Server | 188 | |<-(D)----- Access Token -------| | 189 | | +---------------+ 190 | | 191 | | +---------------+ 192 | |--(E)----- Access Token ------>| Resource | 193 | | | Server | 194 | |<-(F)--- Protected Resource ---| | 195 +--------+ +---------------+ 197 Figure 1: Abstract Protocol Flow 199 The abstract flow illustrated in Figure 1 describes the interaction 200 between the four roles and includes the following steps: 202 (A) The client requests authorization from the resource owner. The 203 authorization request can be made directly to the resource owner 204 (as shown), or preferably indirectly via an intermediary such as 205 an authorization server. 206 (B) The client receives an authorization grant which represents the 207 authorization provided by the resource owner. The authorization 208 grant type depends on the method used by the client and 209 supported by the authorization server to obtain it. 210 (C) The client requests an access token by authenticating with the 211 authorization server using its client credentials (prearranged 212 between the client and authorization server) and presenting the 213 authorization grant. 214 (D) The authorization server validates the client credentials and 215 the authorization grant, and if valid issues an access token. 216 (E) The client requests the protected resource from the resource 217 server and authenticates by presenting the access token. 218 (F) The resource server validates the access token, and if valid, 219 serves the request. 221 1.3. Access Token 223 An access token is a string representing an authorization issued to 224 the client. The string is usually opaque to the client. Tokens 225 represent specific scopes and durations of access, granted by the 226 resource owner, and enforced by the resource server and authorization 227 server. 229 The token may denote an identifier used to retrieve the authorization 230 information, or self-contain the authorization information in a 231 verifiable manner (i.e. a token string consisting of some data and a 232 signature). Additional authentication credentials may be required in 233 order for the client to use a token. 235 The access token provides an abstraction layer, replacing different 236 authorization constructs (e.g. username and password) with a single 237 token understood by the resource server. This abstraction enables 238 issuing access tokens more restrictive than the authorization grant 239 used to obtain them, as well as removing the resource server's need 240 to understand a wide range of authentication methods. 242 Access tokens can have different formats, structures, and methods of 243 utilization (e.g. cryptographic properties) based on the resource 244 server security requirements. Access token attributes and the 245 methods used to access protected resources are beyond the scope of 246 this specification and are defined by companion specifications. 248 1.4. Authorization Grant 250 An authorization grant is a general term used to describe the 251 intermediate credentials representing the resource owner 252 authorization (to access its protected resources), and serves as an 253 abstraction layer. An authorization grant is used by the client to 254 obtain an access token. 256 This specification defines four grant types: authorization code, 257 implicit, resource owner password credentials, and client 258 credentials, as well as an extensibility mechanism for defining 259 additional types. 261 1.4.1. Authorization Code 263 The authorization code is obtained by using an authorization server 264 as an intermediary between the client and resource owner. Instead of 265 requesting authorization directly from the resource owner, the client 266 directs the resource owner to an authorization server (via its user- 267 agent as defined in [RFC2616]), which in turns directs the resource 268 owner back to the client with the authorization code. 270 Before directing the resource owner back to the client with the 271 authorization code, the authorization server authenticates the 272 resource owner and obtains authorization. Because the resource owner 273 only authenticates with the authorization server, the resource 274 owner's credentials are never shared with the client. 276 The authorization code provides a few important security benefits 277 such as the ability to authenticate the client and issuing the access 278 token directly to the client without potentially exposing it to 279 others, including the resource owner. 281 1.4.2. Implicit 283 When an access token is issued to the client directly as the result 284 of the resource owner authorization, without an intermediary 285 authorization grant (such as an authorization code), the grant is 286 considered implicit. 288 When issuing an implicit grant, the authorization server cannot 289 verify the identity of the client, and the access token may be 290 exposed to the resource owner or other applications with access to 291 the resource owner's user-agent. 293 Implicit grants improve the responsiveness and efficiency of some 294 clients (such as a client implemented as an in-browser application) 295 since it reduces the number of round trips required to obtain an 296 access token. 298 1.4.3. Resource Owner Password Credentials 300 The resource owner password credentials (e.g. a username and 301 password) can be used directly as an authorization grant to obtain an 302 access token. The credentials should only be used when there is a 303 high degree of trust between the resource owner and the client (e.g. 304 its computer operating system or a highly privileged application), 305 and when other authorization grant types are not available (such as 306 an authorization code). 308 Even though this grant type requires direct client access to the 309 resource owner credentials, the resource owner credentials are used 310 for a single request and are exchanged for an access token. Unlike 311 the HTTP Basic authentication scheme defined in [RFC2617], this grant 312 type (when combined with a refresh token) eliminates the need for the 313 client to store the resource-owner credentials for future use. 315 1.4.4. Client Credentials 317 The client credentials can be used as an authorization grant when the 318 authorization scope is limited to the protected resources under the 319 control of the client, or to protected resources previously arranged 320 with the authorization server. Client credentials are used as an 321 authorization grant typically when the client is acting on its own 322 behalf (the client is also the resource owner). 324 1.4.5. Extensions 326 Additional grant types may be defined to provide a bridge between 327 OAuth and other protocols. For example, 328 [I-D.ietf-oauth-saml2-bearer] defines a SAML 2.0 329 [OASIS.saml-core-2.0-os] bearer assertion grant type, which can be 330 used to obtain an access token. 332 1.5. Refresh Token 334 A refresh token is optionally issued by the authorization server to 335 the client together with an access token. The client can use the 336 refresh token to request another access token based on the same 337 authorization, without having to involve the resource owner again, or 338 having to retain the original authorization grant used to obtain the 339 initial access token. 341 A refresh token is a string representing the authorization granted to 342 the client by the resource owner. The string is usually opaque to 343 the client. The token may denote an identifier used to retrieve the 344 authorization information, or self-contain the authorization 345 information in a verifiable manner. The refresh token is bound to 346 the client it was issued to, and its usage requires client 347 authentication. 349 The refresh token can be used to obtain a new access token when the 350 current access token expires (access tokens may have a shorter 351 lifetime than authorized by the resource owner), no longer valid, or 352 to obtain additional access tokens with identical or narrower scope. 354 +--------+ Authorization Grant & +---------------+ 355 | |--(A)-------- Client Credentials --------->| | 356 | | | | 357 | |<-(B)----------- Access Token -------------| | 358 | | & Refresh Token | | 359 | | | | 360 | | +----------+ | | 361 | |--(C)---- Access Token ---->| | | | 362 | | | | | | 363 | |<-(D)- Protected Resource --| Resource | | Authorization | 364 | Client | | Server | | Server | 365 | |--(E)---- Access Token ---->| | | | 366 | | | | | | 367 | |<-(F)- Invalid Token Error -| | | | 368 | | +----------+ | | 369 | | | | 370 | | Refresh Token & | | 371 | |--(G)-------- Client Credentials --------->| | 372 | | | | 373 | |<-(H)----------- Access Token -------------| | 374 +--------+ & Optional Refresh Token +---------------+ 376 Figure 2: Refreshing an Expired Access Token 378 The flow illustrated in Figure 2 includes the following steps: 380 (A) The client requests an access token by authenticating with the 381 authorization server using its client credentials, and 382 presenting an authorization grant. 383 (B) The authorization server validates the client credentials and 384 the authorization grant, and if valid issues an access token and 385 a refresh token. 386 (C) The client makes a protected resource requests to the resource 387 server by presenting the access token. 388 (D) The resource server validates the access token, and if valid, 389 serves the request. 390 (E) Steps (C) and (D) repeat until the access token expires. If the 391 client knows the access token expired, it skips to step (G), 392 otherwise it makes another protected resource request. 393 (F) Since the access token is invalid, the resource server returns 394 an invalid token error. 395 (G) The client requests a new access token by authenticating with 396 the authorization server using its client credentials, and 397 presenting the refresh token. 399 (H) The authorization server validates the client credentials and 400 the refresh token, and if valid issues a new access token (and 401 optionally, a new refresh token). 403 1.6. Document Structure 405 This specification is organized into the following sections: 407 o Section 2 - describes the two endpoints used to obtain and utilize 408 the various authorization grant types. 409 o Section 3 - describes client identification and authentication in 410 general, and provides one such method for client authentication 411 using password credentials. 412 o Section 4 - describes the complete flow for each authorization 413 grant type, including requesting authorization, authorization 414 response, and requesting an access token. 415 o Section 5 - describes the common access token response used for 416 all non-implicit authorization grant types. 417 o Section 6 - describes the use of a refresh token to obtain 418 additional access tokens using the same resource owner 419 authorization. 420 o Section 7 - describes how access tokens are used to access 421 protected resources. 422 o Section 8 - describes how to extend certain elements of the 423 protocol. 424 o Section 9 - provides a security analysis of the protocol. 426 1.7. Notational Conventions 428 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 429 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 430 specification are to be interpreted as described in [RFC2119]. 432 This specification uses the Augmented Backus-Naur Form (ABNF) 433 notation of [RFC5234]. 435 Unless otherwise noted, all the protocol parameter names and values 436 are case sensitive. 438 2. Protocol Endpoints 440 The authorization process utilizes two endpoints (HTTP resources): 442 o Authorization endpoint - used to obtain authorization from the 443 resource owner via user-agent redirection. 445 o Token endpoint - used to exchange an authorization grant for an 446 access token, typically with client authentication. 448 Not every authorization grant type utilizes both endpoints. 449 Extension grant types MAY define additional endpoints as needed. 451 2.1. Authorization Endpoint 453 The authorization endpoint is used to interact with the resource 454 owner and obtain authorization which is expressed explicitly as an 455 authorization code (exchanged for an access token), or implicitly by 456 direct issuance of an access token. 458 The authorization server MUST first verify the identity of the 459 resource owner. The way in which the authorization server 460 authenticates the resource owner (e.g. username and password login, 461 session cookies) is beyond the scope of this specification. 463 The means through which the client obtains the location of the 464 authorization endpoint are beyond the scope of this specification but 465 is typically provided in the service documentation. The endpoint URI 466 MAY include a query component as defined by [RFC3986] section 3, 467 which MUST be retained when adding additional query parameters. 469 Requests to the authorization endpoint result in resource owner 470 authentication and the transmission of sensitive information. If the 471 response includes an access token, the authorization server MUST 472 require TLS 1.2 as defined in [RFC5246] and MAY support additional 473 transport-layer mechanisms meeting its security requirements. If the 474 response does not include an access token, the authorization server 475 SHOULD require TLS 1.2 and any additional transport-layer mechanism 476 meeting its security requirements. 478 The authorization server MUST support the use of the HTTP "GET" 479 method [RFC2616] for the authorization endpoint, and MAY support the 480 use of the "POST" method as well. 482 The REQUIRED "response_type" request parameter is used to identify 483 which grant type the client is requesting: authorization code or 484 implicit, described in Section 4.1.1 and Section 4.2.1 respectively. 485 If the request is missing the "response_type" parameter, the 486 authorization server SHOULD return an error response as described in 487 Section 4.1.2.1. 489 Parameters sent without a value MUST be treated as if they were 490 omitted from the request. The authorization server SHOULD ignore 491 unrecognized request parameters. 493 Request and response parameters MUST NOT repeat more than once, 494 unless noted otherwise. 496 2.1.1. Redirection URI 498 The client directs the resource owner's user-agent to the 499 authorization endpoint and includes a redirection URI to which the 500 authorization server will redirect the user-agent back once 501 authorization has been obtained (or denied). The client MAY omit the 502 redirection URI if one has been established between the client and 503 authorization server via other means, such as during the client 504 registration process. 506 The redirection URI MUST be an absolute URI and MAY include a query 507 component, which MUST be retained by the authorization server when 508 adding additional query parameters. 510 The authorization server SHOULD require the client to pre-register 511 their redirection URI or at least certain components such as the 512 scheme, host, port and path. If a redirection URI was registered, 513 the authorization server MUST compare any redirection URI received at 514 the authorization endpoint with the registered URI. 516 The authorization server SHOULD NOT redirect the user-agent to 517 unregistered or untrusted URIs to prevent the endpoint from being 518 used as an open redirector. If no valid redirection URI is 519 available, the authorization server SHOULD inform the resource owner 520 directly of the error. 522 2.2. Token Endpoint 524 The token endpoint is used by the client to obtain an access token by 525 authenticating with the authorization server and presenting its 526 authorization grant or refresh token. The token endpoint is used 527 with every authorization grant except for the implicit grant type 528 (since an access token is issued directly). 530 The means through which the client obtains the location of the token 531 endpoint are beyond the scope of this specification but is typically 532 provided in the service documentation. The endpoint URI MAY include 533 a query component, which MUST be retained when adding additional 534 query parameters. 536 Since requests to the token endpoint result in the transmission of 537 clear-text credentials (in the HTTP request and response), the 538 authorization server MUST require the use of a transport-layer 539 security mechanism when sending requests to the token endpoints. The 540 authorization server MUST support TLS 1.2 as defined in [RFC5246], 541 and MAY support additional transport-layer mechanisms meeting its 542 security requirements. 544 The token endpoint requires client authentication as described in 545 Section 3. The authorization server MAY accept any form of client 546 authentication meeting its security requirements. The client MUST 547 NOT use more than one authentication method in each request. 549 The client MUST use the HTTP "POST" method when making access token 550 requests. 552 Parameters sent without a value MUST be treated as if they were 553 omitted from the request. The authorization server SHOULD ignore 554 unrecognized request parameters. 556 Request and response parameters MUST NOT repeat more than once, 557 unless noted otherwise. 559 3. Client Authentication 561 Client credentials are used to identify and authenticate the client. 562 The client credentials include a client identifier - a unique string 563 issued to the client to identify itself to the authorization server. 564 The client identifier is not a secret, it is exposed to the resource 565 owner, and MUST NOT be used alone for client authentication. Client 566 authentication is accomplished via additional means such as a 567 matching client password. 569 The methods through which the client obtains its client credentials 570 are beyond the scope of this specification. However, the client 571 registration process typically includes gathering relevant 572 information used to inform the resource owner about the client when 573 requesting authorization. 575 Due to the nature of some clients, the authorization server should 576 not make assumptions about the confidentiality of client credentials 577 without establishing trust with the client. The authorization server 578 SHOULD NOT issue client credentials to clients incapable of keeping 579 their credentials confidential (typically determined during the 580 client registration process). 582 In addition, the authorization server MAY allow unauthenticated 583 access token requests when the client identity does not matter (e.g. 584 anonymous client) or when the client identity is established via 585 other means. For readability purposes only, this specification is 586 written under the assumption that the authorization server requires 587 some form of client authentication. However, such language does not 588 affect the authorization server's discretion in allowing 589 unauthenticated client requests. 591 3.1. Client Password Authentication 593 The client password authentication uses a shared symmetric secret to 594 authenticate the client. The client identifier and password are 595 included in the request using the following parameters: 597 client_id 598 REQUIRED. The client identifier. 599 client_secret 600 REQUIRED. The client password. 602 For example (line breaks are for display purposes only): 604 POST /token HTTP/1.1 605 Host: server.example.com 606 Content-Type: application/x-www-form-urlencoded 608 grant_type=authorization_code&client_id=s6BhdRkqt3& 609 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 610 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 612 3.2. Other Client Authentication Methods 614 In cases where client password authentication is not suitable or 615 sufficient, the authorization server MAY support other existing HTTP 616 authentication schemes or define new methods. 618 For example, the authorization server MAY support using the HTTP 619 Basic authentication scheme as defined in [RFC2617] to include the 620 client identifier as the username and client password as the password 621 (line breaks are for display purposes only): 623 POST /token HTTP/1.1 624 Host: server.example.com 625 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 626 Content-Type: application/x-www-form-urlencoded 628 grant_type=authorization_code&code=i1WsRn1uB1& 629 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 631 When using a method other than client password authentication to 632 exchange an authorization code grant type, the authorization server 633 MUST define a method for mapping the client credentials to the client 634 identifier used to obtain the authorization code. 636 4. Obtaining Authorization 638 To request an access token, the client obtains authorization from the 639 resource owner. The authorization is expressed in the form of an 640 authorization grant which the client uses to request the access 641 token. OAuth defines four grant types: authorization code, implicit, 642 resource owner password credentials, and client credentials. It also 643 provides an extension mechanism for defining additional grant types. 645 4.1. Authorization Code 647 The authorization code grant type is suitable for clients capable of 648 maintaining their client credentials confidential (for authenticating 649 with the authorization server) such as a client implemented on a 650 secure server. As a redirection-based flow, the client must be 651 capable of interacting with the resource owner's user-agent 652 (typically a web browser) and capable of receiving incoming requests 653 (via redirection) from the authorization server. 655 +----------+ 656 | resource | 657 | owner | 658 | | 659 +----------+ 660 ^ 661 | 662 (B) 663 +----|-----+ Client Identifier +---------------+ 664 | -+----(A)--- & Redirect URI ------>| | 665 | User- | | Authorization | 666 | Agent -+----(B)-- User authenticates --->| Server | 667 | | | | 668 | -+----(C)-- Authorization Code ---<| | 669 +-|----|---+ +---------------+ 670 | | ^ v 671 (A) (C) | | 672 | | | | 673 ^ v | | 674 +---------+ | | 675 | |>---(D)-- Client Credentials, --------' | 676 | | Authorization Code, | 677 | Client | & Redirect URI | 678 | | | 679 | |<---(E)----- Access Token -------------------' 680 +---------+ (w/ Optional Refresh Token) 682 Figure 3: Authorization Code Flow 684 The flow illustrated in Figure 3 includes the following steps: 686 (A) The client initiates the flow by directing the resource owner's 687 user-agent to the authorization endpoint. The client includes 688 its client identifier, requested scope, local state, and a 689 redirection URI to which the authorization server will send the 690 user-agent back once access is granted (or denied). 691 (B) The authorization server authenticates the resource owner (via 692 the user-agent) and establishes whether the resource owner 693 grants or denies the client's access request. 694 (C) Assuming the resource owner grants access, the authorization 695 server redirects the user-agent back to the client using the 696 redirection URI provided earlier. The redirection URI includes 697 an authorization code and any local state provided by the client 698 earlier. 700 (D) The client requests an access token from the authorization 701 server's token endpoint by authenticating using its client 702 credentials, and includes the authorization code received in the 703 previous step. The client includes the redirection URI used to 704 obtain the authorization code for verification. 705 (E) The authorization server validates the client credentials, the 706 authorization code, and ensures the redirection URI received 707 matches the URI used to redirect the client in step (C). If 708 valid, responds back with an access token. 710 4.1.1. Authorization Request 712 The client constructs the request URI by adding the following 713 parameters to the query component of the authorization endpoint URI 714 using the "application/x-www-form-urlencoded" format as defined by 715 [W3C.REC-html401-19991224]: 717 response_type 718 REQUIRED. Value MUST be set to "code". 719 client_id 720 REQUIRED. The client identifier as described in Section 3. 721 redirect_uri 722 REQUIRED, unless a redirection URI has been established between 723 the client and authorization server via other means. Described 724 in Section 2.1.1. 725 scope 726 OPTIONAL. The scope of the access request expressed as a list 727 of space-delimited, case sensitive strings. The value is 728 defined by the authorization server. If the value contains 729 multiple space-delimited strings, their order does not matter, 730 and each string adds an additional access range to the 731 requested scope. 732 state 733 OPTIONAL. An opaque value used by the client to maintain state 734 between the request and callback. The authorization server 735 includes this value when redirecting the user-agent back to the 736 client. 738 The client directs the resource owner to the constructed URI using an 739 HTTP redirection response, or by other means available to it via the 740 user-agent. 742 For example, the client directs the user-agent to make the following 743 HTTP request using transport-layer security (line breaks are for 744 display purposes only): 746 GET /authorize?response_type=code&client_id=s6BhdRkqt3& 747 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 748 Host: server.example.com 750 The authorization server validates the request to ensure all required 751 parameters are present and valid. If the request is valid, the 752 authorization server authenticates the resource owner and obtains an 753 authorization decision (by asking the resource owner or by 754 establishing approval via other means). 756 When a decision is established, the authorization server directs the 757 user-agent to the provided client redirection URI using an HTTP 758 redirection response, or by other means available to it via the user- 759 agent. 761 4.1.2. Authorization Response 763 If the resource owner grants the access request, the authorization 764 server issues an authorization code and delivers it to the client by 765 adding the following parameters to the query component of the 766 redirection URI using the "application/x-www-form-urlencoded" format: 768 code 769 REQUIRED. The authorization code generated by the 770 authorization server. The authorization code SHOULD expire 771 shortly after it is issued to minimize the risk of leaks. The 772 client MUST NOT reuse the authorization code. If an 773 authorization code is used more than once, the authorization 774 server MAY revoke all tokens previously issued based on that 775 authorization code. The authorization code is bound to the 776 client identifier and redirection URI. 777 state 778 REQUIRED if the "state" parameter was present in the client 779 authorization request. Set to the exact value received from 780 the client. 782 For example, the authorization server redirects the user-agent by 783 sending the following HTTP response: 785 HTTP/1.1 302 Found 786 Location: https://client.example.com/cb?code=i1WsRn1uB1 788 The client SHOULD ignore unrecognized response parameters. The 789 authorization code string size is left undefined by this 790 specification. The client should avoid making assumptions about code 791 value sizes. The authorization server should document the size of 792 any value it issues. 794 4.1.2.1. Error Response 796 If the request fails due to a missing, invalid, or mismatching 797 redirection URI, or if the client identifier provided is invalid, the 798 authorization server SHOULD inform the resource owner of the error, 799 and MUST NOT redirect the user-agent to the invalid redirection URI. 801 If the resource owner denies the access request or if the request 802 fails for reasons other than a missing or invalid redirection URI, 803 the authorization server informs the client by adding the following 804 parameters to the query component of the redirection URI using the 805 "application/x-www-form-urlencoded" format: 807 error 808 REQUIRED. A single error code from the following: 809 invalid_request 810 The request is missing a required parameter, includes an 811 unsupported parameter or parameter value, or is otherwise 812 malformed. 813 unauthorized_client 814 The client is not authorized to request an authorization 815 code using this method. 816 access_denied 817 The resource owner or authorization server denied the 818 request. 819 unsupported_response_type 820 The authorization server does not support obtaining an 821 authorization code using this method. 822 invalid_scope 823 The requested scope is invalid, unknown, or malformed. 824 a 4xx or 5xx HTTP status code (except for 400 and 401) 825 [[ Pending Consensus ]] The authorization server MAY set 826 the "error" parameter value to a numerical HTTP status 827 code from the 4xx or 5xx range, with the exception of the 828 400 (Bad Request) and 401 (Unauthorized) status codes. 829 For example, if the service is temporarily unavailable, 830 the authorization server MAY return an error response 831 with "error" set to "503". 832 error_description 833 OPTIONAL. A human-readable text providing additional 834 information, used to assist in the understanding and resolution 835 of the error occurred. 837 error_uri 838 OPTIONAL. A URI identifying a human-readable web page with 839 information about the error, used to provide the resource owner 840 with additional information about the error. 841 state 842 REQUIRED if a valid "state" parameter was present in the client 843 authorization request. Set to the exact value received from 844 the client. 846 For example, the authorization server redirects the user-agent by 847 sending the following HTTP response: 849 HTTP/1.1 302 Found 850 Location: https://client.example.com/cb?error=access_denied 852 4.1.3. Access Token Request 854 The client makes a request to the token endpoint by adding the 855 following parameter using the "application/x-www-form-urlencoded" 856 format in the HTTP request entity-body: 858 grant_type 859 REQUIRED. Value MUST be set to "authorization_code". 860 code 861 REQUIRED. The authorization code received from the 862 authorization server. 863 redirect_uri 864 REQUIRED. The redirection URI used by the authorization server 865 to return the authorization response in the previous step. 867 The client includes its authentication credentials as described in 868 Section 3 870 For example, the client makes the following HTTP request by including 871 its client credentials via the "client_id" and "client_secret" 872 parameters, and using transport-layer security (line breaks are for 873 display purposes only): 875 POST /token HTTP/1.1 876 Host: server.example.com 877 Content-Type: application/x-www-form-urlencoded 879 grant_type=authorization_code&client_id=s6BhdRkqt3& 880 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 881 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 883 The authorization server MUST: 885 o Validate the client credentials and ensure that the authorization 886 code was issued to that client. 887 o Verify that the authorization code is valid, and that the 888 redirection URI matches the redirection URI used by the 889 authorization server to deliver the authorization code. 891 4.1.4. Access Token Response 893 If the access token request is valid and authorized, the 894 authorization server issues an access token and optional refresh 895 token as described in Section 5.1. If the request client 896 authentication failed or is invalid, the authorization server returns 897 an error response as described in Section 5.2. 899 An example successful response: 901 HTTP/1.1 200 OK 902 Content-Type: application/json 903 Cache-Control: no-store 905 { 906 "access_token":"SlAV32hkKG", 907 "token_type":"example", 908 "expires_in":3600, 909 "refresh_token":"8xLOxBtZp8", 910 "example_parameter":"example_value" 911 } 913 4.2. Implicit Grant 915 The implicit grant type is suitable for clients incapable of 916 maintaining their client credentials confidential (for authenticating 917 with the authorization server) such as client applications residing 918 in a user-agent, typically implemented in a browser using a scripting 919 language such as JavaScript. 921 As a redirection-based flow, the client must be capable of 922 interacting with the resource owner's user-agent (typically a web 923 browser) and capable of receiving incoming requests (via redirection) 924 from the authorization server. 926 Unlike the authorization code grant type in which the client makes 927 separate requests for authorization and access token, the client 928 receives the access token as the result of the authorization request. 930 Using the implicit grant type does not include client authentication 931 since the client is unable to maintain their credential 932 confidentiality (the client resides on the resource owner's computer 933 or device which makes the client credentials accessible and 934 exploitable). Because the access token is encoded into the 935 redirection URI, it may be exposed to the resource owner and other 936 applications residing on its computer or device. 938 +----------+ 939 | Resource | 940 | Owner | 941 | | 942 +----------+ 943 ^ 944 | 945 (B) 946 +----|-----+ Client Identifier +---------------+ 947 | -+----(A)--- & Redirect URI ----->| | 948 | User- | | Authorization | 949 | Agent -|----(B)-- User authenticates -->| Server | 950 | | | | 951 | |<---(C)---- Redirect URI ------<| | 952 | | with Access Token +---------------+ 953 | | in Fragment 954 | | +---------------+ 955 | |----(D)---- Redirect URI ------>| Web Server | 956 | | without Fragment | with Client | 957 | | | Resource | 958 | (F) |<---(E)------- Script ---------<| | 959 | | +---------------+ 960 +-|--------+ 961 | | 962 (A) (G) Access Token 963 | | 964 ^ v 965 +---------+ 966 | | 967 | Client | 968 | | 969 +---------+ 971 Figure 4: Implicit Grant Flow 973 The flow illustrated in Figure 4 includes the following steps: 975 (A) The client initiates the flow by directing the resource owner's 976 user-agent to the authorization endpoint. The client includes 977 its client identifier, requested scope, local state, and a 978 redirection URI to which the authorization server will send the 979 user-agent back once access is granted (or denied). 980 (B) The authorization server authenticates the resource owner (via 981 the user-agent) and establishes whether the resource owner 982 grants or denies the client's access request. 983 (C) Assuming the resource owner grants access, the authorization 984 server redirects the user-agent back to the client using the 985 redirection URI provided earlier. The redirection URI includes 986 the access token in the URI fragment. 987 (D) The user-agent follows the redirection instructions by making a 988 request to the web server (does not include the fragment). The 989 user-agent retains the fragment information locally. 990 (E) The web server returns a web page (typically an HTML document 991 with an embedded script) capable of accessing the full 992 redirection URI including the fragment retained by the user- 993 agent, and extracting the access token (and other parameters) 994 contained in the fragment. 995 (F) The user-agent executes the script provided by the web server 996 locally, which extracts the access token and passes it to the 997 client. 999 4.2.1. Authorization Request 1001 The client constructs the request URI by adding the following 1002 parameters to the query component of the authorization endpoint URI 1003 using the "application/x-www-form-urlencoded" format: 1005 response_type 1006 REQUIRED. Value MUST be set to "token". 1007 client_id 1008 REQUIRED. The client identifier as described in Section 3. 1009 redirect_uri 1010 REQUIRED, unless a redirection URI has been established between 1011 the client and authorization server via other means. Described 1012 in Section 2.1.1. 1013 scope 1014 OPTIONAL. The scope of the access request expressed as a list 1015 of space-delimited, case sensitive strings. The value is 1016 defined by the authorization server. If the value contains 1017 multiple space-delimited strings, their order does not matter, 1018 and each string adds an additional access range to the 1019 requested scope. 1021 state 1022 OPTIONAL. An opaque value used by the client to maintain state 1023 between the request and callback. The authorization server 1024 includes this value when redirecting the user-agent back to the 1025 client. 1027 The client directs the resource owner to the constructed URI using an 1028 HTTP redirection response, or by other means available to it via the 1029 user-agent. 1031 For example, the client directs the user-agent to make the following 1032 HTTP request using transport-layer security (line breaks are for 1033 display purposes only): 1035 GET /authorize?response_type=token&client_id=s6BhdRkqt3& 1036 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 1037 Host: server.example.com 1039 The authorization server validates the request to ensure all required 1040 parameters are present and valid. If the request is valid, the 1041 authorization server authenticates the resource owner and obtains an 1042 authorization decision (by asking the resource owner or by 1043 establishing approval via other means). 1045 When a decision is established, the authorization server directs the 1046 user-agent to the provided client redirection URI using an HTTP 1047 redirection response, or by other means available to it via the user- 1048 agent. 1050 4.2.2. Access Token Response 1052 If the resource owner grants the access request, the authorization 1053 server issues an access token and delivers it to the client by adding 1054 the following parameters to the fragment component of the redirection 1055 URI using the "application/x-www-form-urlencoded" format: 1057 access_token 1058 REQUIRED. The access token issued by the authorization server. 1059 token_type 1060 REQUIRED. The type of the token issued as described in 1061 Section 7.1. Value is case insensitive. 1062 expires_in 1063 OPTIONAL. The duration in seconds of the access token 1064 lifetime. For example, the value "3600" denotes that the 1065 access token will expire in one hour from the time the response 1066 was generated. 1068 scope 1069 OPTIONAL. The scope of the access request expressed as a list 1070 of space-delimited, case sensitive strings. The value is 1071 defined by the authorization server. If the value contains 1072 multiple space-delimited strings, their order does not matter, 1073 and each string adds an additional access range to the 1074 requested scope. The authorization server SHOULD include the 1075 parameter if the requested scope is different from the one 1076 requested by the client. 1077 state 1078 REQUIRED if the "state" parameter was present in the client 1079 authorization request. Set to the exact value received from 1080 the client. 1082 For example, the authorization server redirects the user-agent by 1083 sending the following HTTP response (URI line breaks are for display 1084 purposes only): 1086 HTTP/1.1 302 Found 1087 Location: http://example.com/rd#access_token=FJQbwq9& 1088 token_type=example&expires_in=3600 1090 The client SHOULD ignore unrecognized response parameters. The 1091 access token string size is left undefined by this specification. 1092 The client should avoid making assumptions about value sizes. The 1093 authorization server should document the size of any value it issues. 1095 4.2.2.1. Error Response 1097 If the request fails due to a missing, invalid, or mismatching 1098 redirection URI, or if the client identifier provided is invalid, the 1099 authorization server SHOULD inform the resource owner of the error, 1100 and MUST NOT redirect the user-agent to the invalid redirection URI. 1102 If the resource owner denies the access request or if the request 1103 fails for reasons other than a missing or invalid redirection URI, 1104 the authorization server informs the client by adding the following 1105 parameters to the fragment component of the redirection URI using the 1106 "application/x-www-form-urlencoded" format: 1108 error 1109 REQUIRED. A single error code from the following: 1111 invalid_request 1112 The request is missing a required parameter, includes an 1113 unsupported parameter or parameter value, or is otherwise 1114 malformed. 1115 unauthorized_client 1116 The client is not authorized to request an access token 1117 using this method. 1118 access_denied 1119 The resource owner or authorization server denied the 1120 request. 1121 unsupported_response_type 1122 The authorization server does not support obtaining an 1123 access token using this method. 1124 invalid_scope 1125 The requested scope is invalid, unknown, or malformed. 1126 a 4xx or 5xx HTTP status code (except for 400 and 401) 1127 [[ Pending Consensus ]] The authorization server MAY set 1128 the "error" parameter value to a numerical HTTP status 1129 code from the 4xx or 5xx range, with the exception of the 1130 400 (Bad Request) and 401 (Unauthorized) status codes. 1131 For example, if the service is temporarily unavailable, 1132 the authorization server MAY return an error response 1133 with "error" set to "503". 1134 error_description 1135 OPTIONAL. A human-readable text providing additional 1136 information, used to assist in the understanding and resolution 1137 of the error occurred. 1138 error_uri 1139 OPTIONAL. A URI identifying a human-readable web page with 1140 information about the error, used to provide the resource owner 1141 with additional information about the error. 1142 state 1143 REQUIRED if a valid "state" parameter was present in the client 1144 authorization request. Set to the exact value received from 1145 the client. 1147 For example, the authorization server redirects the user-agent by 1148 sending the following HTTP response: 1150 HTTP/1.1 302 Found 1151 Location: https://client.example.com/cb#error=access_denied 1153 4.3. Resource Owner Password Credentials 1155 The resource owner password credentials grant type is suitable in 1156 cases where the resource owner has a trust relationship with the 1157 client, such as its computer operating system or a highly privileged 1158 application. The authorization server should take special care when 1159 enabling the grant type, and only when other flows are not viable. 1161 The grant type is suitable for clients capable of obtaining the 1162 resource owner credentials (username and password, typically using an 1163 interactive form). It is also used to migrate existing clients using 1164 direct authentication schemes such as HTTP Basic or Digest 1165 authentication to OAuth by converting the stored credentials with an 1166 access token. 1168 +----------+ 1169 | Resource | 1170 | Owner | 1171 | | 1172 +----------+ 1173 v 1174 | 1175 (A) Password Credentials 1176 | 1177 v 1178 +---------+ +---------------+ 1179 | | Client Credentials | | 1180 | |>--(B)---- & Resource Owner ----->| | 1181 | Client | Password Credentials | Authorization | 1182 | | | Server | 1183 | |<--(C)---- Access Token ---------<| | 1184 | | (w/ Optional Refresh Token) | | 1185 +---------+ +---------------+ 1187 Figure 5: Resource Owner Password Credentials Flow 1189 The flow illustrated in Figure 5 includes the following steps: 1191 (A) The resource owner provides the client with its username and 1192 password. 1193 (B) The client requests an access token from the authorization 1194 server's token endpoint by authenticating using its client 1195 credentials, and includes the credentials received from the 1196 resource owner. 1198 (C) The authorization server validates the resource owner 1199 credentials and the client credentials and issues an access 1200 token. 1202 4.3.1. Authorization Request and Response 1204 The method through which the client obtains the resource owner 1205 credentials is beyond the scope of this specification. The client 1206 MUST discard the credentials once an access token has been obtained. 1208 4.3.2. Access Token Request 1210 The client makes a request to the token endpoint by adding the 1211 following parameter using the "application/x-www-form-urlencoded" 1212 format in the HTTP request entity-body: 1214 grant_type 1215 REQUIRED. Value MUST be set to "password". 1216 username 1217 REQUIRED. The resource owner username. 1218 password 1219 REQUIRED. The resource owner password. 1220 scope 1221 OPTIONAL. The scope of the access request expressed as a list 1222 of space-delimited, case sensitive strings. The value is 1223 defined by the authorization server. If the value contains 1224 multiple space-delimited strings, their order does not matter, 1225 and each string adds an additional access range to the 1226 requested scope. 1228 The client includes its authentication credentials as described in 1229 Section 3 1231 For example, the client makes the following HTTP request by including 1232 its client credentials via the "client_id" and "client_secret" 1233 parameters, and using transport-layer security (line breaks are for 1234 display purposes only): 1236 POST /token HTTP/1.1 1237 Host: server.example.com 1238 Content-Type: application/x-www-form-urlencoded 1240 grant_type=password&client_id=s6BhdRkqt3& 1241 client_secret=47HDu8s&username=johndoe&password=A3ddj3w 1243 The authorization server MUST: 1245 o Validate the client credentials. 1246 o Validate the resource owner password credentials. 1248 4.3.3. Access Token Response 1250 If the access token request is valid and authorized, the 1251 authorization server issues an access token and optional refresh 1252 token as described in Section 5.1. If the request failed client 1253 authentication or is invalid, the authorization server returns an 1254 error response as described in Section 5.2. 1256 An example successful response: 1258 HTTP/1.1 200 OK 1259 Content-Type: application/json 1260 Cache-Control: no-store 1262 { 1263 "access_token":"SlAV32hkKG", 1264 "token_type":"example", 1265 "expires_in":3600, 1266 "refresh_token":"8xLOxBtZp8", 1267 "example_parameter":"example_value" 1268 } 1270 4.4. Client Credentials 1272 The client can request an access token using only its client 1273 credentials when the client is requesting access to the protected 1274 resources under its control, or those of another resource owner which 1275 has been previously arranged with the authorization server (the 1276 method of which is beyond the scope of this specification). 1278 +---------+ +---------------+ 1279 | | | | 1280 | |>--(A)--- Client Credentials ---->| Authorization | 1281 | Client | | Server | 1282 | |<--(B)---- Access Token ---------<| | 1283 | | (w/ Optional Refresh Token) | | 1284 +---------+ +---------------+ 1286 Figure 6: Client Credentials Flow 1288 The flow illustrated in Figure 6 includes the following steps: 1290 (A) The client requests an access token from the token endpoint by 1291 authenticating using its client credentials. 1292 (B) The authorization server validates the client credentials and 1293 issues an access token. 1295 4.4.1. Authorization Request and Response 1297 Since the client credentials are used as the authorization grant, no 1298 additional authorization request is needed as the client is already 1299 in the possession of its client credentials. 1301 4.4.2. Access Token Request 1303 The client makes a request to the token endpoint by adding the 1304 following parameter using the "application/x-www-form-urlencoded" 1305 format in the HTTP request entity-body: 1307 grant_type 1308 REQUIRED. Value MUST be set to "client_credentials". 1309 scope 1310 OPTIONAL. The scope of the access request expressed as a list 1311 of space-delimited, case sensitive strings. The value is 1312 defined by the authorization server. If the value contains 1313 multiple space-delimited strings, their order does not matter, 1314 and each string adds an additional access range to the 1315 requested scope. 1317 The client includes its authentication credentials as described in 1318 Section 3 1320 For example, the client makes the following HTTP request by including 1321 its client credentials via the "client_id" and "client_secret" 1322 parameters, and using transport-layer security (line breaks are for 1323 display purposes only): 1325 POST /token HTTP/1.1 1326 Host: server.example.com 1327 Content-Type: application/x-www-form-urlencoded 1329 grant_type=client_credentials&client_id=s6BhdRkqt3& 1330 client_secret=47HDu8s 1332 The authorization server MUST validate the client credentials. 1334 4.4.3. Access Token Response 1336 If the access token request is valid and authorized, the 1337 authorization server issues an access token and optional refresh 1338 token as described in Section 5.1. If the request failed client 1339 authentication or is invalid, the authorization server returns an 1340 error response as described in Section 5.2. 1342 An example successful response: 1344 HTTP/1.1 200 OK 1345 Content-Type: application/json 1346 Cache-Control: no-store 1348 { 1349 "access_token":"SlAV32hkKG", 1350 "token_type":"example", 1351 "expires_in":3600, 1352 "refresh_token":"8xLOxBtZp8", 1353 "example_parameter":"example_value" 1354 } 1356 4.5. Extensions 1358 The client uses an extension grant type by specifying the grant type 1359 using an absolute URI (defined by the authorization server) as the 1360 value of the "grant_type" parameter of the token endpoint, and by 1361 adding any additional parameters necessary. 1363 For example, to request an access token using a SAML 2.0 assertion 1364 grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client 1365 makes the following HTTP request using transport-layer security (line 1366 breaks are for display purposes only): 1368 POST /token HTTP/1.1 1369 Host: server.example.com 1370 Content-Type: application/x-www-form-urlencoded 1372 grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F 1373 saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ 1374 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 1376 5. Issuing an Access Token 1378 If the access token request is valid and authorized, the 1379 authorization server issues an access token and optional refresh 1380 token as described in Section 5.1. If the request failed client 1381 authentication or is invalid, the authorization server returns an 1382 error response as described in Section 5.2. 1384 5.1. Successful Response 1386 The authorization server issues an access token and optional refresh 1387 token, and constructs the response by adding the following parameters 1388 to the entity body of the HTTP response with a 200 (OK) status code: 1390 access_token 1391 REQUIRED. The access token issued by the authorization server. 1392 token_type 1393 REQUIRED. The type of the token issued as described in 1394 Section 7.1. Value is case insensitive. 1395 expires_in 1396 OPTIONAL. The duration in seconds of the access token 1397 lifetime. For example, the value "3600" denotes that the 1398 access token will expire in one hour from the time the response 1399 was generated. 1400 refresh_token 1401 OPTIONAL. The refresh token which can be used to obtain new 1402 access tokens using the same authorization grant as described 1403 in Section 6. 1404 scope 1405 OPTIONAL. The scope of the access request expressed as a list 1406 of space-delimited, case sensitive strings. The value is 1407 defined by the authorization server. If the value contains 1408 multiple space-delimited strings, their order does not matter, 1409 and each string adds an additional access range to the 1410 requested scope. The authorization server SHOULD include the 1411 parameter if the requested scope is different from the one 1412 requested by the client. 1414 The parameters are included in the entity body of the HTTP response 1415 using the "application/json" media type as defined by [RFC4627]. The 1416 parameters are serialized into a JSON structure by adding each 1417 parameter at the highest structure level. Parameter names and string 1418 values are included as JSON strings. Numerical values are included 1419 as JSON numbers. 1421 The authorization server MUST include the HTTP "Cache-Control" 1422 response header field [RFC2616] with a value of "no-store" in any 1423 response containing tokens, secrets, or other sensitive information. 1425 For example: 1427 HTTP/1.1 200 OK 1428 Content-Type: application/json 1429 Cache-Control: no-store 1431 { 1432 "access_token":"SlAV32hkKG", 1433 "token_type":"example", 1434 "expires_in":3600, 1435 "refresh_token":"8xLOxBtZp8", 1436 "example_parameter":"example_value" 1437 } 1439 The client SHOULD ignore unrecognized response parameters. The sizes 1440 of tokens and other values received from the authorization server are 1441 left undefined. The client should avoid making assumptions about 1442 value sizes. The authorization server should document the size of 1443 any value it issues. 1445 5.2. Error Response 1447 The authorization server responds with an HTTP 400 (Bad Request) 1448 status code and includes the following parameters with the response: 1450 error 1451 REQUIRED. A single error code from the following: 1452 invalid_request 1453 The request is missing a required parameter, includes an 1454 unsupported parameter or parameter value, repeats a 1455 parameter, includes multiple credentials, utilizes more 1456 than one mechanism for authenticating the client, or is 1457 otherwise malformed. 1458 invalid_client 1459 Client authentication failed (e.g. unknown client, no 1460 client credentials included, multiple client credentials 1461 included, or unsupported credentials type). The 1462 authorization server MAY return an HTTP 401 1463 (Unauthorized) status code to indicate which HTTP 1464 authentication schemes are supported. If the client 1465 attempted to authenticate via the "Authorization" request 1466 header field, the authorization server MUST respond with 1467 an HTTP 401 (Unauthorized) status code, and include the 1468 "WWW-Authenticate" response header field matching the 1469 authentication scheme used by the client. 1471 invalid_grant 1472 The provided authorization grant is invalid, expired, 1473 revoked, does not match the redirection URI used in the 1474 authorization request, or was issued to another client. 1475 unauthorized_client 1476 The authenticated client is not authorized to use this 1477 authorization grant type. 1478 unsupported_grant_type 1479 The authorization grant type is not supported by the 1480 authorization server. 1481 invalid_scope 1482 The requested scope is invalid, unknown, malformed, or 1483 exceeds the scope granted by the resource owner. 1484 error_description 1485 OPTIONAL. A human-readable text providing additional 1486 information, used to assist in the understanding and resolution 1487 of the error occurred. 1488 error_uri 1489 OPTIONAL. A URI identifying a human-readable web page with 1490 information about the error, used to provide the resource owner 1491 with additional information about the error. 1493 The parameters are included in the entity body of the HTTP response 1494 using the "application/json" media type as defined by [RFC4627]. The 1495 parameters are serialized into a JSON structure by adding each 1496 parameter at the highest structure level. Parameter names and string 1497 values are included as JSON strings. Numerical values are included 1498 as JSON numbers. 1500 For example: 1502 HTTP/1.1 400 Bad Request 1503 Content-Type: application/json 1504 Cache-Control: no-store 1506 { 1507 "error":"invalid_request" 1508 } 1510 [[ Pending Consensus ]] If the authorization server encounters an 1511 error condition other than the 400 (Bad Request) and 401 1512 (Unauthorized) responses described above (e.g. the service is 1513 temporarily unavailable), the authorization server SHOULD include an 1514 error response in the entity body, and set the "error" parameter 1515 value to the numerical HTTP status code returned. 1517 For example: 1519 HTTP/1.1 503 Service Unavailable 1520 Content-Type: application/json 1522 { 1523 "error":"503" 1524 } 1526 6. Refreshing an Access Token 1528 The client makes a request to the token endpoint by adding the 1529 following parameter using the "application/x-www-form-urlencoded" 1530 format in the HTTP request entity-body: 1532 grant_type 1533 REQUIRED. Value MUST be set to "refresh_token". 1534 refresh_token 1535 REQUIRED. The refresh token issued to the client. 1536 scope 1537 OPTIONAL. The scope of the access request expressed as a list 1538 of space-delimited, case sensitive strings. The value is 1539 defined by the authorization server. If the value contains 1540 multiple space-delimited strings, their order does not matter, 1541 and each string adds an additional access range to the 1542 requested scope. The requested scope MUST be equal or lesser 1543 than the scope originally granted by the resource owner, and if 1544 omitted is treated as equal to the scope originally granted by 1545 the resource owner. 1547 The client includes its authentication credentials as described in 1548 Section 3. 1550 For example, the client makes the following HTTP request by including 1551 its client credentials via the "client_id" and "client_secret" 1552 parameters, and using transport-layer security (line breaks are for 1553 display purposes only): 1555 POST /token HTTP/1.1 1556 Host: server.example.com 1557 Content-Type: application/x-www-form-urlencoded 1559 grant_type=refresh_token&client_id=s6BhdRkqt3& 1560 client_secret=8eSEIpnqmM&refresh_token=n4E9O119d 1562 The authorization server MUST validate the client credentials, ensure 1563 that the refresh token was issued to the authenticated client, 1564 validate the refresh token, and verify that the resource owner's 1565 authorization is still valid. If valid and authorized, the 1566 authorization server issues an access token as described in 1567 Section 5.1. If the request failed verification or is invalid, the 1568 authorization server returns an error response as described in 1569 Section 5.2. 1571 The authorization server MAY issue a new refresh token, in which 1572 case, the client MUST discard the old refresh token and replace it 1573 with the new refresh token. 1575 7. Accessing Protected Resources 1577 The client accesses protected resources by presenting the access 1578 token to the resource server. The resource server MUST validate the 1579 access token and ensure it has not expired and that its scope covers 1580 the requested resource. The methods used by the resource server to 1581 validate the access token (as well as any error responses) are beyond 1582 the scope of this specification, but generally involve an interaction 1583 or coordination between the resource server and the authorization 1584 server. 1586 The method in which the client utilized the access token to 1587 authenticate with the resource server depends on the type of access 1588 token issued by the authorization server. Typically, it involves 1589 using the HTTP "Authorization" request header field [RFC2617] with an 1590 authentication scheme defined by the access token type specification. 1592 7.1. Access Token Types 1594 The access token type provides the client with the information 1595 required to successfully utilize the access token to make a protected 1596 resource request (along with type-specific attributes). 1598 For example, the "bearer" token type defined in 1599 [I-D.ietf-oauth-v2-bearer] is utilized by simply including the access 1600 token string in the request: 1602 GET /resource/1 HTTP/1.1 1603 Host: example.com 1604 Authorization: Bearer h480djs93hd8 1606 while the "mac" token type defined in [I-D.hammer-oauth-v2-mac-token] 1607 is utilized by issuing a token secret together with the access token 1608 which is used to sign certain components of the HTTP requests: 1610 GET /resource/1 HTTP/1.1 1611 Host: example.com 1612 Authorization: MAC token="h480djs93hd8", 1613 timestamp="137131200", 1614 nonce="dj83hs9s", 1615 signature="kDZvddkndxvhGRXZhvuDjEWhGeE=" 1617 Each access token type definition specifies the additional attributes 1618 (if any) sent to the client together with the "access_token" response 1619 parameter. It also defines the HTTP authentication method used to 1620 include the access token when making a protected resource request. 1622 8. Extensibility 1624 8.1. Defining Access Token Types 1626 Access token types can be defined in one of two ways: registered in 1627 the access token type registry (following the procedures in 1628 Section 10.1), or use a unique absolute URI as its name. 1630 Types utilizing a URI name SHOULD be limited to vendor-specific 1631 implementations that are not commonly applicable, and are specific to 1632 the implementation details of the resource server where they are 1633 used. 1635 All other types MUST be registered. Type names MUST conform to the 1636 type-name ABNF. If the type definition includes a new HTTP 1637 authentication scheme, the type name SHOULD be identical to the HTTP 1638 authentication scheme name (as defined by [RFC2617]). 1640 type-name = 1*name-char 1641 name-char = "-" / "." / "_" / DIGIT / ALPHA 1643 8.2. Defining New Endpoint Parameters 1645 New request or response parameters for use with the authorization 1646 endpoint or the token endpoint are defined and registered in the 1647 parameters registry following the procedure in Section 10.2. 1649 Parameter names MUST conform to the param-name ABNF and parameter 1650 values syntax MUST be well-defined (e.g., using ABNF, or a reference 1651 to the syntax of an existing parameter). 1653 param-name = 1*name-char 1654 name-char = "-" / "." / "_" / DIGIT / ALPHA 1656 Unregistered vendor-specific parameter extensions that are not 1657 commonly applicable, and are specific to the implementation details 1658 of the authorization server where they are used SHOULD utilize a 1659 vendor-specific prefix that is not likely to conflict with other 1660 registered values (e.g. begin with 'companyname_'). 1662 8.3. Defining New Authorization Grant Types 1664 New authorization grant types can be defined by assigning them a 1665 unique absolute URI for use with the "grant_type" parameter. If the 1666 extension grant type requires additional token endpoint parameters, 1667 they MUST be registered in the OAuth parameters registry as described 1668 by Section 10.2. 1670 8.4. Defining Additional Error Codes 1672 [[ Pending Consensus ]] 1674 In cases where protocol extensions (i.e. access token types, 1675 extension parameters, or extension grant types) require additional 1676 error codes to be used with the authorization code grant error 1677 response (Section 4.1.2.1), the implicit grant error response 1678 (Section 4.2.2.1), or the token error response (Section 5.2), such 1679 error codes MAY be defined. 1681 Extension error codes MUST be registered (following the procedures in 1682 Section 10.3) if the extension they are used in conjunction with is 1683 registered. Additional error codes used with unregistered extensions 1684 MAY be registered. 1686 Error codes MUST conform to the error-code ABNF, and SHOULD be 1687 prefixed by an identifying name when possible. For example, an error 1688 identifying an invalid value set to the extension parameter "example" 1689 should be named "example_invalid". 1691 error-code = ALPHA *error-char 1692 error-char = "-" / "." / "_" / DIGIT / ALPHA 1694 9. Security Considerations 1696 [[ TBD ]] 1698 10. IANA Considerations 1700 10.1. The OAuth Access Token Type Registry 1702 This specification establishes the OAuth access token type registry. 1704 Access token types are registered on the advice of one or more 1705 Designated Experts (appointed by the IESG or their delegate), with a 1706 Specification Required (using terminology from [RFC5226]). However, 1707 to allow for the allocation of values prior to publication, the 1708 Designated Expert(s) may approve registration once they are satisfied 1709 that such a specification will be published. 1711 Registration requests should be sent to the [TBD]@ietf.org mailing 1712 list for review and comment, with an appropriate subject (e.g., 1713 "Request for access toke type: example"). [[ Note to RFC-EDITOR: The 1714 name of the mailing list should be determined in consultation with 1715 the IESG and IANA. Suggested name: oauth-ext-review. ]] 1717 Within at most 14 days of the request, the Designated Expert(s) will 1718 either approve or deny the registration request, communicating this 1719 decision to the review list and IANA. Denials should include an 1720 explanation and, if applicable, suggestions as to how to make the 1721 request successful. 1723 Decisions (or lack thereof) made by the Designated Expert can be 1724 first appealed to Application Area Directors (contactable using 1725 app-ads@tools.ietf.org email address or directly by looking up their 1726 email addresses on http://www.iesg.org/ website) and, if the 1727 appellant is not satisfied with the response, to the full IESG (using 1728 the iesg@iesg.org mailing list). 1730 IANA should only accept registry updates from the Designated 1731 Expert(s), and should direct all requests for registration to the 1732 review mailing list. 1734 10.1.1. Registration Template 1736 Type name: 1737 The name requested (e.g., "example"). 1739 Additional Token Endpoint Response Parameters: 1740 Additional response parameters returned together with the 1741 "access_token" parameter. New parameters MUST be separately 1742 registered in the OAuth parameters registry as described by 1743 Section 10.2. 1744 HTTP Authentication Scheme(s): 1745 The HTTP authentication scheme name(s), if any, used to 1746 authenticate protected resources requests using access token of 1747 this type. 1748 Change controller: 1749 For standards-track RFCs, state "IETF". For others, give the name 1750 of the responsible party. Other details (e.g., postal address, 1751 e-mail address, home page URI) may also be included. 1752 Specification document(s): 1753 Reference to document that specifies the parameter, preferably 1754 including a URI that can be used to retrieve a copy of the 1755 document. An indication of the relevant sections may also be 1756 included, but is not required. 1758 10.2. The OAuth Parameters Registry 1760 This specification establishes the OAuth parameters registry. 1762 Additional parameters for inclusion in the authorization endpoint 1763 request, the authorization endpoint response, the token endpoint 1764 request, or the token endpoint response, are registered on the advice 1765 of one or more Designated Experts (appointed by the IESG or their 1766 delegate), with a Specification Required (using terminology from 1767 [RFC5226]). However, to allow for the allocation of values prior to 1768 publication, the Designated Expert(s) may approve registration once 1769 they are satisfied that such a specification will be published. 1771 Registration requests should be sent to the [TBD]@ietf.org mailing 1772 list for review and comment, with an appropriate subject (e.g., 1773 "Request for parameter: example"). [[ Note to RFC-EDITOR: The name of 1774 the mailing list should be determined in consultation with the IESG 1775 and IANA. Suggested name: oauth-ext-review. ]] 1777 Within at most 14 days of the request, the Designated Expert(s) will 1778 either approve or deny the registration request, communicating this 1779 decision to the review list and IANA. Denials should include an 1780 explanation and, if applicable, suggestions as to how to make the 1781 request successful. 1783 Decisions (or lack thereof) made by the Designated Expert can be 1784 first appealed to Application Area Directors (contactable using 1785 app-ads@tools.ietf.org email address or directly by looking up their 1786 email addresses on http://www.iesg.org/ website) and, if the 1787 appellant is not satisfied with the response, to the full IESG (using 1788 the iesg@iesg.org mailing list). 1790 IANA should only accept registry updates from the Designated 1791 Expert(s), and should direct all requests for registration to the 1792 review mailing list. 1794 10.2.1. Registration Template 1796 Parameter name: 1797 The name requested (e.g., "example"). 1798 Parameter usage location: 1799 The location(s) where parameter can be used. The possible 1800 locations are: authorization request, authorization response, 1801 token request, or token response. 1802 Change controller: 1803 For standards-track RFCs, state "IETF". For others, give the name 1804 of the responsible party. Other details (e.g., postal address, 1805 e-mail address, home page URI) may also be included. 1806 Specification document(s): 1807 Reference to document that specifies the parameter, preferably 1808 including a URI that can be used to retrieve a copy of the 1809 document. An indication of the relevant sections may also be 1810 included, but is not required. 1812 10.2.2. Initial Registry Contents 1814 The OAuth Parameters Registry's initial contents are: 1816 o Parameter name: client_id 1817 o Parameter usage location: authorization request, token request 1818 o Change controller: IETF 1819 o Specification document(s): [[ this document ]] 1821 o Parameter name: client_secret 1822 o Parameter usage location: token request 1823 o Change controller: IETF 1824 o Specification document(s): [[ this document ]] 1826 o Parameter name: response_type 1827 o Parameter usage location: authorization request 1828 o Change controller: IETF 1829 o Specification document(s): [[ this document ]] 1831 o Parameter name: redirect_uri 1832 o Parameter usage location: authorization request, token request 1833 o Change controller: IETF 1834 o Specification document(s): [[ this document ]] 1836 o Parameter name: scope 1837 o Parameter usage location: authorization request, authorization 1838 response, token request, token response 1839 o Change controller: IETF 1840 o Specification document(s): [[ this document ]] 1842 o Parameter name: state 1843 o Parameter usage location: authorization request, authorization 1844 response 1845 o Change controller: IETF 1846 o Specification document(s): [[ this document ]] 1848 o Parameter name: code 1849 o Parameter usage location: authorization response, token request 1850 o Change controller: IETF 1851 o Specification document(s): [[ this document ]] 1853 o Parameter name: error_description 1854 o Parameter usage location: authorization response, token response 1855 o Change controller: IETF 1856 o Specification document(s): [[ this document ]] 1858 o Parameter name: error_uri 1859 o Parameter usage location: authorization response, token response 1860 o Change controller: IETF 1861 o Specification document(s): [[ this document ]] 1863 o Parameter name: grant_type 1864 o Parameter usage location: token request 1865 o Change controller: IETF 1866 o Specification document(s): [[ this document ]] 1868 o Parameter name: access_token 1869 o Parameter usage location: authorization response, token response 1870 o Change controller: IETF 1871 o Specification document(s): [[ this document ]] 1873 o Parameter name: token_type 1874 o Parameter usage location: authorization response, token response 1875 o Change controller: IETF 1876 o Specification document(s): [[ this document ]] 1878 o Parameter name: expires_in 1879 o Parameter usage location: authorization response, token response 1880 o Change controller: IETF 1881 o Specification document(s): [[ this document ]] 1883 o Parameter name: username 1884 o Parameter usage location: token request 1885 o Change controller: IETF 1886 o Specification document(s): [[ this document ]] 1888 o Parameter name: password 1889 o Parameter usage location: token request 1890 o Change controller: IETF 1891 o Specification document(s): [[ this document ]] 1893 o Parameter name: refresh_token 1894 o Parameter usage location: token request, token response 1895 o Change controller: IETF 1896 o Specification document(s): [[ this document ]] 1898 10.3. The OAuth Extensions Error Registry 1900 [[ Pending Consensus ]] 1902 This specification establishes the OAuth extensions error registry. 1904 Additional error codes used together with other protocol extensions 1905 (i.e. extension grant types, access token types, or extension 1906 parameters) are registered on the advice of one or more Designated 1907 Experts (appointed by the IESG or their delegate), with a 1908 Specification Required (using terminology from [RFC5226]). However, 1909 to allow for the allocation of values prior to publication, the 1910 Designated Expert(s) may approve registration once they are satisfied 1911 that such a specification will be published. 1913 Registration requests should be sent to the [TBD]@ietf.org mailing 1914 list for review and comment, with an appropriate subject (e.g., 1915 "Request for error code: example"). [[ Note to RFC-EDITOR: The name 1916 of the mailing list should be determined in consultation with the 1917 IESG and IANA. Suggested name: oauth-ext-review. ]] 1919 Within at most 14 days of the request, the Designated Expert(s) will 1920 either approve or deny the registration request, communicating this 1921 decision to the review list and IANA. Denials should include an 1922 explanation and, if applicable, suggestions as to how to make the 1923 request successful. 1925 Decisions (or lack thereof) made by the Designated Expert can be 1926 first appealed to Application Area Directors (contactable using 1927 app-ads@tools.ietf.org email address or directly by looking up their 1928 email addresses on http://www.iesg.org/ website) and, if the 1929 appellant is not satisfied with the response, to the full IESG (using 1930 the iesg@iesg.org mailing list). 1932 IANA should only accept registry updates from the Designated 1933 Expert(s), and should direct all requests for registration to the 1934 review mailing list. 1936 10.3.1. Registration Template 1938 Error name: 1939 The name requested (e.g., "example"). 1940 Error usage location: 1941 The location(s) where the error can be used. The possible 1942 locations are: authorization code grant error response 1943 (Section 4.1.2.1), implicit grant error response 1944 (Section 4.2.2.1), or token error response (Section 5.2). 1945 Related protocol extension: 1946 The name of the extension grant type, access token type, or 1947 extension parameter, the error code is used in conjunction with. 1948 Change controller: 1949 For standards-track RFCs, state "IETF". For others, give the name 1950 of the responsible party. Other details (e.g., postal address, 1951 e-mail address, home page URI) may also be included. 1952 Specification document(s): 1953 Reference to document that specifies the error code, preferably 1954 including a URI that can be used to retrieve a copy of the 1955 document. An indication of the relevant sections may also be 1956 included, but is not required. 1958 11. Acknowledgements 1960 This specification is the work of the OAuth Working Group which 1961 includes dozens of active and dedicated participants. In particular, 1962 the following individuals contributed ideas, feedback, and wording 1963 which shaped and formed the final specification: 1965 Michael Adams, Andrew Arnott, Dirk Balfanz, Blaine Cook, Brian 1966 Campbell, Leah Culver, Bill de hOra, Brian Eaton, Brian Ellin, Igor 1967 Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, 1968 Brent Goldman, Kristoffer Gronowski, Justin Hart, Craig Heath, Phil 1969 Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen 1970 Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Paul 1971 Madsen, Alastair Mair, Eve Maler, James Manger, Laurence Miao, Chuck 1972 Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, 1973 Marius Scurtescu, Naitik Shah, Luke Shepard, Justin Smith, Jeremy 1974 Suriel, Christian Stuebner, Paul Tarjan, Allen Tom, Franklin Tse, 1975 Nick Walker, Skylar Woodward. 1977 The initial OAuth 2.0 protocol specification was edited by David 1978 Recordon, based on two previous publications: the OAuth 1.0 community 1979 specification [RFC5849], and OAuth WRAP (OAuth Web Resource 1980 Authorization Profiles) [I-D.draft-hardt-oauth-01]. 1982 The OAuth 1.0 community specification was edited by Eran Hammer-Lahav 1983 and authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. 1984 Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, 1985 Kellan Elliott-McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie, 1986 Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran 1987 Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy 1988 Smith. 1990 The OAuth WRAP specification was edited by Dick Hardt and authored by 1991 Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. 1993 Appendix A. Editor's Notes 1995 While many people contributed to this specification throughout its 1996 long journey, the editor would like to acknowledge and thank a few 1997 individuals for their outstanding and invaluable efforts leading up 1998 to the publication of this specification. It is these individuals 1999 without whom this work would not have existed, or reached its 2000 successful conclusion. 2002 David Recordon for continuously being one of OAuth's most valuable 2003 assets, bringing pragmatism and urgency to the work, and helping 2004 shape it from its very beginning, as well as being one of the best 2005 collaborators I had the pleasure of working with. 2007 Mark Nottingham for introducing OAuth to the IETF and setting the 2008 community on this course. Lisa Dusseault for her support and 2009 guidance as the Application area director. Blaine Cook, Peter Saint- 2010 Andre, and Hannes Tschofenig for their work as working group chairs. 2012 James Manger for his creative ideas and always insightful feedback. 2013 Brian Campbell, Torsten Lodderstedt, Chuck Mortimore, Justin Richer, 2014 Marius Scurtescu, and Luke Shepard for their continued participation 2015 and valuable feedback. 2017 Special thanks goes to Mike Curtis and Yahoo! for their unconditional 2018 support of this work for over three years. 2020 12. References 2022 12.1. Normative References 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2025 Requirement Levels", BCP 14, RFC 2119, March 1997. 2027 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2028 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2029 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2031 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2032 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2033 Authentication: Basic and Digest Access Authentication", 2034 RFC 2617, June 1999. 2036 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2037 Resource Identifier (URI): Generic Syntax", STD 66, 2038 RFC 3986, January 2005. 2040 [RFC4627] Crockford, D., "The application/json Media Type for 2041 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 2043 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2044 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2045 May 2008. 2047 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2048 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2050 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2051 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2053 [W3C.REC-html401-19991224] 2054 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 2055 Specification", World Wide Web Consortium 2056 Recommendation REC-html401-19991224, December 1999, 2057 . 2059 12.2. Informative References 2061 [I-D.draft-hardt-oauth-01] 2062 Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth 2063 Web Resource Authorization Profiles", January 2010. 2065 [I-D.hammer-oauth-v2-mac-token] 2066 Hammer-Lahav, E., "HTTP Authentication: MAC 2067 Authentication", draft-hammer-oauth-v2-mac-token-02 (work 2068 in progress), January 2011. 2070 [I-D.ietf-oauth-saml2-bearer] 2071 Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion 2072 Grant Type Profile for OAuth 2.0", 2073 draft-ietf-oauth-saml2-bearer-03 (work in progress), 2074 February 2011. 2076 [I-D.ietf-oauth-v2-bearer] 2077 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 2078 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-02 2079 (work in progress), January 2011. 2081 [OASIS.saml-core-2.0-os] 2082 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 2083 "Assertions and Protocol for the OASIS Security Assertion 2084 Markup Language (SAML) V2.0", OASIS Standard saml-core- 2085 2.0-os, March 2005. 2087 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 2088 April 2010. 2090 Authors' Addresses 2092 Eran Hammer-Lahav (editor) 2093 Yahoo! 2095 Email: eran@hueniverse.com 2096 URI: http://hueniverse.com 2098 David Recordon 2099 Facebook 2101 Email: dr@fb.com 2102 URI: http://www.davidrecordon.com/ 2104 Dick Hardt 2105 Microsoft 2107 Email: dick.hardt@gmail.com 2108 URI: http://dickhardt.org/