idnits 2.17.1 draft-ietf-oauth-v2-12.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 (January 21, 2011) is 4836 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) == Unused Reference: 'RFC2045' is defined on line 1924, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 1931, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 1940, but no explicit reference was found in the text == Unused Reference: 'RFC2828' is defined on line 1942, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 1945, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 1948, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 1952, but no explicit reference was found in the text == Unused Reference: 'RFC5849' is defined on line 1969, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-09 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** 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) ** Obsolete normative reference: RFC 5849 (Obsoleted by RFC 6749) == Outdated reference: A later version (-05) exists of draft-hammer-oauth-v2-mac-token-01 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-00 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-v2-bearer-01 Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 2 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: July 25, 2011 D. Hardt 7 Microsoft 8 January 21, 2011 10 The OAuth 2.0 Authorization Protocol 11 draft-ietf-oauth-v2-12 13 Abstract 15 This specification describes the OAuth 2.0 authorization protocol. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 25, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 6 55 1.4. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 7 56 1.5. Notational Conventions . . . . . . . . . . . . . . . . . . 9 57 2. Client Authentication . . . . . . . . . . . . . . . . . . . . 9 58 2.1. Client Password Authentication . . . . . . . . . . . . . . 9 59 2.2. Other Client Authentication Methods . . . . . . . . . . . 10 60 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 11 61 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . . 11 62 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 12 63 4. Requesting an Access Token . . . . . . . . . . . . . . . . . . 13 64 4.1. Authorization Code . . . . . . . . . . . . . . . . . . . . 13 65 4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . . 19 66 4.3. Resource Owner Password Credentials . . . . . . . . . . . 24 67 4.4. Client Credentials . . . . . . . . . . . . . . . . . . . . 26 68 4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 69 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 28 70 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 28 71 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . . 30 72 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 31 73 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 32 74 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . . 33 75 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33 76 8.1. Defining Access Token Types . . . . . . . . . . . . . . . 33 77 8.2. Defining New Endpoint Parameters . . . . . . . . . . . . . 34 78 8.3. Defining New Authorization Grant Types . . . . . . . . . . 34 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 81 10.1. The OAuth Access Token Type Registry . . . . . . . . . . . 35 82 10.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 36 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 39 84 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 39 85 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 86 Appendix D. Document History . . . . . . . . . . . . . . . . . . 39 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 45 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 92 1. Introduction 94 In the traditional client-server authentication model, the client 95 accesses a protected resource on the server by authenticating with 96 the server using the resource owner's credentials. In order to 97 provide third-party applications access to protected resources, the 98 resource owner shares its credentials with the third-party. This 99 creates several problems and limitations: 101 o Third-party applications are required to store the resource- 102 owner's credentials for future use, typically a password in clear- 103 text. 104 o Servers are required to support password authentication, despite 105 the security weaknesses created by passwords. 106 o Third-party applications gain overly broad access to the resource- 107 owner's protected resources, leaving resource owners without any 108 ability to restrict duration or access to a limited subset of 109 resources. 110 o Resource owners cannot revoke access to an individual third-party 111 without revoking access to all third-parties, and must do so by 112 changing their password. 114 OAuth addresses these issues by introducing an authorization layer 115 and separating the role of the client from that of the resource 116 owner. In OAuth, the client requests access to resources controlled 117 by the resource owner and hosted by the resource server, and is 118 issued a different set of credentials than those of the resource 119 owner. 121 Instead of using the resource owner's credentials to access protected 122 resources, the client obtains an access token - a string denoting a 123 specific scope, duration, and other access attributes. Access tokens 124 are issued to third-party clients by an authorization server with the 125 approval of the resource owner. The client uses the access token to 126 access the protected resources hosted by the resource server. 128 For example, a web user (resource owner) can grant a printing service 129 (client) access to her protected photos stored at a photo sharing 130 service (resource server), without sharing her username and password 131 with the printing service. Instead, she authenticates directly with 132 a server trusted by the photo sharing service (authorization server) 133 which issues the printing service delegation-specific credentials 134 (access token). 136 1.1. Roles 138 OAuth includes four roles working together to grant and provide 139 access to protected resources - access restricted resources which 140 require authentication to access: 142 resource owner 143 An entity capable of granting access to a protected resource. 144 When the resource owner is a person, it is referred to as an end- 145 user. 146 resource server 147 The server hosting the protected resources, capable of accepting 148 and responding to protected resource requests using access tokens. 149 client 150 An application making protected resource requests on behalf of the 151 resource owner and with its authorization. 152 authorization server 153 The server issuing access tokens to the client after successfully 154 authenticating the resource owner and obtaining authorization. 156 The interaction between the authorization server and resource server 157 is beyond the scope of this specification. The authorization server 158 may be the same server as the resource server or a separate entity. 159 A single authorization server may issue access tokens accepted by 160 multiple resource servers. 162 When interacting with the authorization server, the client identifies 163 itself using a set of client credentials which include a client 164 identifier and other authentication attributes. The means through 165 which the client obtains its credentials are beyond the scope of this 166 specification, but typically involve registration with the 167 authorization server. 169 +--------+ +---------------+ 170 | |--(A)- Authorization Request ->| Resource | 171 | | | Owner | 172 | |<-(B)-- Authorization Grant ---| | 173 | | +---------------+ 174 | | 175 | | Authorization Grant & +---------------+ 176 | |--(C)--- Client Credentials -->| Authorization | 177 | Client | | Server | 178 | |<-(D)----- Access Token -------| | 179 | | +---------------+ 180 | | 181 | | +---------------+ 182 | |--(E)----- Access Token ------>| Resource | 183 | | | Server | 184 | |<-(F)--- Protected Resource ---| | 185 +--------+ +---------------+ 186 Figure 1: Abstract Protocol Flow 188 The abstract flow illustrated in Figure 1 describes the interaction 189 between the four roles and includes the following steps: 191 (A) The client requests authorization from the resource owner. The 192 authorization request can be made directly to the resource owner 193 (as shown), or preferably indirectly via an intermediary such as 194 an authorization server. 195 (B) The client receives an authorization grant which represents the 196 authorization provided by the resource owner. The authorization 197 grant type depends on the method used by the client and 198 supported by the authorization server to obtain it. 199 (C) The client requests an access token by authenticating with the 200 authorization server using its client credentials (prearranged 201 between the client and authorization server) and presenting the 202 authorization grant. 203 (D) The authorization server validates the client credentials and 204 the authorization grant, and if valid issues an access token. 205 (E) The client requests the protected resource from the resource 206 server and authenticates by presenting the access token. 207 (F) The resource server validates the access token, and if valid, 208 serves the request. 210 1.2. Access Token 212 An access token is a string representing an authorization issued to 213 the client. The string is usually opaque to the client. Tokens 214 represent specific scopes and durations of access, granted by the 215 resource owner, and enforced by the resource server and authorization 216 server. 218 The token may denote an identifier used to retrieve the authorization 219 information, or self-contain the authorization information in a 220 verifiable manner (i.e. a token string consisting of some data and a 221 signature). Tokens may be pure capabilities. Additional 222 authentication credentials may be required in order for the client to 223 use a token. 225 The access token provides an abstraction layer, replacing different 226 authorization constructs (e.g. username and password) with a single 227 token understood by the resource server. This abstraction enables 228 issuing access tokens more restrictive than the authorization grant 229 used to obtain them, as well as removing the resource server's need 230 to understand a wide range of authentication methods. 232 Access tokens can have different formats, structures, and methods of 233 utilization (e.g. cryptographic properties) based on the resource 234 server security requirements. Access token attributes and the 235 methods used to access protected resources are beyond the scope of 236 this specification and are defined by companion specifications. 238 1.3. Authorization Grant 240 An authorization grant is a general term used to describe the 241 intermediate credentials representing the resource owner 242 authorization, and serves as an abstraction layer. An authorization 243 grant is used by the client to obtain an access token. 245 1.3.1. Authorization Code 247 The authorization code is obtained by using an authorization server 248 as an intermediary between the client and resource owner. Instead of 249 requesting authorization directly from the resource owner, the client 250 directs the resource owner to an authorization server (via its user- 251 agent), which in turns directs the resource owner back to the client 252 with the authorization code. 254 Before directing the resource owner back to the client with the 255 authorization code, the authorization server authenticates the 256 resource owner and obtains authorization. Because the resource owner 257 only authenticates with the authorization server, the resource 258 owner's credentials are never shared with the client. 260 The authorization code provides a few important security benefits 261 such as the ability to authenticate the client and issuing the access 262 token directly to the client without potentially exposing it to 263 others, including the resource owner. 265 1.3.2. Implicit 267 An implicit grant is issued when the resource owner's authorization 268 is expressed directly as an access token, without using an 269 intermediate credential. The implicit grant is issued in a similar 270 manner as an authorization code, but instead of the resource owner 271 being redirected back to the client with the authorization code, it 272 is redirected back with an access token and its related attributes. 274 When issuing an implicit grant, the authorization server cannot 275 verify the identity of the client, and the access token may be 276 exposed to the resource owner or other applications with access to 277 the resource owner's user-agent. 279 Implicit grants improve the responsiveness and efficiency of some 280 clients (such as a client implemented as an in-browser application) 281 since it reduces the number of round trip required to obtain an 282 access token. 284 1.3.3. Resource Owner Password Credentials 286 The resource owner password credentials (e.g. a username and 287 password) can be used directly as an authorization grant to obtain an 288 access token. The credentials should only be used when there is a 289 high degree of trust between the resource owner and the client (e.g. 290 its computer operating system or a highly privileged application), 291 and when other authorization grant types are not available (such as 292 an authorization code). 294 Even though this grant type requires direct client access to the 295 resource owner credentials, the resource owner credentials are used 296 for a single request and are exchanged for an access token. Unlike 297 the HTTP Basic authentication scheme defined in [RFC2617], this grant 298 type eliminates the need for the client to store the resource-owner 299 credentials for future use. 301 1.3.4. Client Credentials 303 The client credentials can be used as an authorization grant when the 304 authorization scope is limited to the protected resources under the 305 control of the client, or to protected resources previously arranged 306 with the authorization server. Client credentials are used as an 307 authorization grant typically when the client is acting on its own 308 behalf (the client is also the resource owner). 310 1.3.5. Extensions 312 Additional grant types may be defined to provide a bridge between 313 OAuth and other trust frameworks. For example, 314 [I-D.ietf-oauth-saml2-bearer] defines a SAML 2.0 315 [OASIS.saml-core-2.0-os] bearer assertion grant type, which can be 316 used to obtain an access token. 318 1.4. Refresh Token 320 A refresh token is optionally issued by the authorization server to 321 the client together with an access token. The client can use the 322 refresh token to request another access token based on the same 323 authorization, without having to involve the resource owner again, or 324 having to retain the original authorization grant used to obtain the 325 initial access token. 327 A refresh token is a string representing the authorization granted to 328 the client by the resource owner. The string is usually opaque to 329 the client. The token may denote an identifier used to retrieve the 330 authorization information, or self-contain the authorization 331 information in a verifiable manner. 333 The refresh token can be used to obtain a new access token when the 334 current access token expires (access tokens may have a shorter 335 lifetime than authorized by the resource owner), or to obtain 336 additional access tokens with identical or narrower scope. 338 +--------+ Access Grant & +---------------+ 339 | |--(A)-------- Client Credentials --------->| | 340 | | | | 341 | |<-(B)----------- Access Token -------------| | 342 | | & Refresh Token | | 343 | | | | 344 | | +----------+ | | 345 | |--(C)---- Access Token ---->| | | | 346 | | | | | | 347 | |<-(D)- Protected Resource --| Resource | | Authorization | 348 | Client | | Server | | Server | 349 | |--(E)---- Access Token ---->| | | | 350 | | | | | | 351 | |<-(F)- Invalid Token Error -| | | | 352 | | +----------+ | | 353 | | | | 354 | | Refresh Token & | | 355 | |--(G)-------- Client Credentials --------->| | 356 | | | | 357 | |<-(H)----------- Access Token -------------| | 358 +--------+ & Optional Refresh Token +---------------+ 360 Figure 2: Refreshing an Expired Access Token 362 The flow illustrated in Figure 2 includes the following steps: 364 (A) The client requests an access token by authenticating with the 365 authorization server using its client credentials, and 366 presenting an authorization grant. 367 (B) The authorization server validates the client credentials and 368 the authorization grant, and if valid issues an access token and 369 a refresh token. 370 (C) The client makes a protected resource requests to the resource 371 server by presenting the access token. 373 (D) The resource server validates the access token, and if valid, 374 serves the request. 375 (E) Steps (C) and (D) repeat until the access token expires. If the 376 client knows the access token expired, it skips to step (G), 377 otherwise it makes another protected resource request. 378 (F) Since the access token is invalid (expired), the resource server 379 returns an invalid token error. 380 (G) The client requests a new access token by authenticating with 381 the authorization server using its client credentials, and 382 presenting the refresh token. 383 (H) The authorization server validates the client credentials and 384 the refresh token, and if valid issues a new access token (and 385 optionally, a new refresh token). 387 1.5. Notational Conventions 389 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 390 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 391 specification are to be interpreted as described in [RFC2119]. 393 This specification uses the Augmented Backus-Naur Form (ABNF) 394 notation of [I-D.ietf-httpbis-p1-messaging]. Additionally, the 395 following rules are included from [RFC3986]: URI-reference; and from 396 [I-D.ietf-httpbis-p1-messaging]: OWS, RWS, and quoted-string. 398 Unless otherwise noted, all the protocol parameter names and values 399 are case sensitive. 401 2. Client Authentication 403 Client credentials are used to identify and authenticate the client. 404 The client credentials include a client identified - a unique string 405 issued to the client to identify itself to the authorization server. 406 The methods through which the client obtains its client credentials 407 are beyond the scope of this specification. 409 Due to the nature of some clients, the authorization server SHOULD 410 NOT make assumptions about the confidentiality of client credentials 411 without establishing trust with the client. The authorization server 412 SHOULD NOT issue client credentials to clients incapable of keeping 413 their secrets confidential. 415 2.1. Client Password Authentication 417 The client password authentication uses a shared symmetric secret to 418 authenticate the client. The client identifier and password are 419 included in the request using the following parameters: 421 client_id 422 REQUIRED. The client identifier. 423 client_secret 424 REQUIRED. The client password. 426 For example (line breaks are for display purposes only): 428 POST /token HTTP/1.1 429 Host: server.example.com 430 Content-Type: application/x-www-form-urlencoded 432 grant_type=authorization_code&client_id=s6BhdRkqt3& 433 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 434 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 436 2.2. Other Client Authentication Methods 438 In cases where client password authentication is not suitable or 439 sufficient, the authorization server MAY support other existing HTTP 440 authentication schemes or define new methods. In addition, the 441 authorization server MAY allow unauthenticated access token requests 442 when the client identity does not matter (e.g. anonymous client) or 443 when the client identity is established via other means. 445 For example, the authorization server MAY support using the HTTP 446 Basic authentication scheme as defined in [RFC2617] to include the 447 client identifier as the username and client password as the password 448 (line breaks are for display purposes only): 450 POST /token HTTP/1.1 451 Host: server.example.com 452 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 453 Content-Type: application/x-www-form-urlencoded 455 grant_type=authorization_code&code=i1WsRn1uB1& 456 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 458 When using a method other than client password authentication to 459 exchange an authorization code grant type, the authorization server 460 MUST define a method for mapping the client credentials to the client 461 identifier used to obtain the authorization code. 463 3. Protocol Endpoints 465 The authorization process utilizes two endpoints: 467 o Authorization endpoint - used to obtain authorization from the 468 resource owner via user-agent redirection. 469 o Token endpoint - used to exchange an authorization grant for an 470 access token, typically with client authentication. 472 Not every authorization grant flow utilizes both endpoints. 473 Extension grant types MAY define additional endpoints as needed. 475 3.1. Authorization Endpoint 477 The authorization endpoint is used to interact with the resource 478 owner and obtain authorization which is expressed explicitly as an 479 authorization code (exchanged for an access token), or implicitly by 480 direct issuance of an access token. 482 The authorization server MUST first verify the identity of the 483 resource owner. The way in which the authorization server 484 authenticates the resource owner (e.g. username and password login, 485 session cookies) is beyond the scope of this specification. 487 The location of the authorization endpoint can be found in the 488 service documentation. The endpoint URI MAY include a query 489 component as defined by [RFC3986] section 3, which MUST be retained 490 when adding additional query parameters. 492 Requests to the authorization endpoint result in user authentication 493 and the transmission of sensitive information. If the response 494 includes an access token, the authorization server MUST require TLS 495 1.2 as defined in [RFC5246] and MAY support additional transport- 496 layer mechanisms meeting its security requirements. If the response 497 does not include an access token, the authorization server SHOULD 498 require TLS 1.2 and any additional transport-layer mechanism meeting 499 its security requirements. 501 The authorization server MUST support the use of the HTTP "GET" 502 method for the authorization endpoint, and MAY support the use of the 503 "POST" method as well. 505 Parameters sent without a value MUST be treated as if they were 506 omitted from the request. The authorization server SHOULD ignore 507 unrecognized request parameters. 509 3.1.1. Redirection URI 511 The client directs the resource owner's user-agent to the 512 authorization endpoint and includes a redirection URI to which the 513 authorization server will redirect the user-agent back once 514 authorization has been obtained (or denied). The client MAY omit the 515 redirection URI if one has been established between the client and 516 authorization server via other means, such as during the client 517 registration process. 519 The redirection URI MUST be an absolute URI and MAY include a query 520 component, which MUST be retained by the authorization server when 521 adding additional query parameters. 523 The authorization server SHOULD require the client to pre-register 524 their redirection URI or at least certain components such as the 525 scheme, host, port and path. If a redirection URI was registered, 526 the authorization server MUST compare any redirection URI received at 527 the authorization endpoint with the registered URI. 529 The authorization server SHOULD NOT redirect the user-agent to 530 unregistered or untrusted URIs to prevent the endpoint from being 531 used as an open redirector. If no valid redirection URI is 532 available, the authorization server SHOULD inform the resource owner 533 directly of the error. 535 3.2. Token Endpoint 537 The token endpoint is used by the client to obtain an access token by 538 authenticating with the authorization server and presenting its 539 authorization grant. The token endpoint is used with every 540 authorization grant except for the implicit grant type (since an 541 access token is issued directly). 543 The location of the token endpoint can be found in the service 544 documentation. The endpoint URI MAY include a query component, which 545 MUST be retained when adding additional query parameters. 547 Since requests to the token endpoint result in the transmission of 548 clear-text credentials (in the HTTP request and response), the 549 authorization server MUST require the use of a transport-layer 550 security mechanism when sending requests to the token endpoints. The 551 authorization server MUST support TLS 1.2 as defined in [RFC5246], 552 and MAY support additional transport-layer mechanisms meeting its 553 security requirements. 555 The token endpoint requires client authentication as described in 556 Section 2 . The authorization server MAY accept any form of client 557 authentication meeting its security requirements. The client MUST 558 NOT use more than one authentication method in each request. 560 The client MUST use the HTTP "POST" method when making access token 561 requests. 563 Parameters sent without a value MUST be treated as if they were 564 omitted from the request. The authorization server SHOULD ignore 565 unrecognized request parameters. 567 4. Requesting an Access Token 569 The client obtains an access token by requesting authorization from 570 the resource owner. The authorization is expressed in the form of an 571 authorization grant which the client exchanges for an access token. 572 OAuth defines four grant types: authorization code, implicit, 573 resource owner password credentials, and client credentials, as well 574 as an extension mechanism for defining additional grant types. 576 4.1. Authorization Code 578 The authorization code flow is suitable for clients capable of 579 maintaining their client credentials confidential (for authenticating 580 with the authorization server) such as a client implemented on a 581 secure server. As a redirection-based profile, the client must be 582 capable of interacting with the resource owner's user-agent 583 (typically a web browser) and capable of receiving incoming requests 584 (via redirection) from the authorization server. 586 +----------+ 587 | resource | 588 | owner | 589 | | 590 +----------+ 591 ^ 592 | 593 (B) 594 +----|-----+ Client Identifier +---------------+ 595 | -+----(A)--- & Redirect URI ------>| | 596 | User- | | Authorization | 597 | Agent -+----(B)-- User authenticates --->| Server | 598 | | | | 599 | -+----(C)-- Authorization Code ---<| | 600 +-|----|---+ +---------------+ 601 | | ^ v 602 (A) (C) | | 603 | | | | 604 ^ v | | 605 +---------+ | | 606 | |>---(D)-- Client Credentials, --------' | 607 | | Authorization Code, | 608 | Client | & Redirect URI | 609 | | | 610 | |<---(E)----- Access Token -------------------' 611 +---------+ (w/ Optional Refresh Token) 613 Figure 3: Authorization Code Flow 615 The flow illustrated in Figure 3 includes the following steps: 617 (A) The client initiates the flow by directing the resource owner's 618 user-agent to the authorization endpoint. The client includes 619 its client identifier, requested scope, local state, and a 620 redirection URI to which the authorization server will send the 621 user-agent back once access is granted (or denied). 622 (B) The authorization server authenticates the resource owner (via 623 the user-agent) and establishes whether the resource owner 624 grants or denies the client's access request. 625 (C) Assuming the resource owner grants access, the authorization 626 server redirects the user-agent back to the client using the 627 redirection URI provided earlier. The redirection URI includes 628 an authorization code. 630 (D) The client requests an access token from the authorization 631 server's token endpoint by authenticating using its client 632 credentials, and includes the authorization code received in the 633 previous step. 634 (E) The authorization server validates the client credentials and 635 the authorization code and if valid, responds back with an 636 access token. 638 4.1.1. Authorization Request 640 The client constructs the request URI by adding the following 641 parameters to the query component of the authorization endpoint URI 642 using the "application/x-www-form-urlencoded" format as defined by 643 [W3C.REC-html401-19991224]: 645 response_type 646 REQUIRED. Value MUST be set to "code". 647 client_id 648 REQUIRED. The client identifier as described in Section 2. 649 redirect_uri 650 REQUIRED, unless a redirection URI has been established between 651 the client and authorization server via other means. Described 652 in Section 3.1.1. 653 scope 654 OPTIONAL. The scope of the access request expressed as a list 655 of space-delimited strings. The value is defined by the 656 authorization server. If the value contains multiple space- 657 delimited strings, their order does not matter, and each string 658 adds an additional access range to the requested scope. 659 state 660 OPTIONAL. An opaque value used by the client to maintain state 661 between the request and callback. The authorization server 662 includes this value when redirecting the user-agent back to the 663 client. 665 The client directs the resource owner to the constructed URI using an 666 HTTP redirection response, or by other means available to it via the 667 user-agent. 669 For example, the client directs the user-agent to make the following 670 HTTP request using transport-layer security (line breaks are for 671 display purposes only): 673 GET /authorize?response_type=code&client_id=s6BhdRkqt3& 674 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 675 Host: server.example.com 677 The authorization server validates the request to ensure all required 678 parameters are present and valid. If the request is valid, the 679 authorization server authenticates the resource owner and obtains an 680 authorization decision (by asking the resource owner or by 681 establishing approval via other means). 683 When a decision is established, the authorization server directs the 684 user-agent to the provided client redirection URI using an HTTP 685 redirection response, or by other means available to it via the user- 686 agent. 688 4.1.2. Authorization Response 690 If the resource owner grants the access request, the authorization 691 server issues an authorization code and delivers it to the client by 692 adding the following parameters to the query component of the 693 redirection URI using the "application/x-www-form-urlencoded" format: 695 code 696 REQUIRED. The authorization code generated by the 697 authorization server. The authorization code SHOULD expire 698 shortly after it is issued to minimize the risk of leaks. The 699 client MUST NOT reuse the authorization code. If an 700 authorization code is used more than once, the authorization 701 server MAY revoke all tokens previously issued based on that 702 authorization code. The authorization code is bound to the 703 client identifier and redirection URI. 704 state 705 REQUIRED if the "state" parameter was present in the client 706 authorization request. Set to the exact value received from 707 the client. 709 For example, the authorization server redirects the user-agent by 710 sending the following HTTP response: 712 HTTP/1.1 302 Found 713 Location: https://client.example.com/cb?code=i1WsRn1uB1 715 The client SHOULD ignore unrecognized response parameters. The 716 authorization code string size is left undefined by this 717 specification. The clients should avoid making assumptions about 718 code value sizes. The authorization server should document the size 719 of any value is issues. 721 4.1.2.1. Error Response 723 If the request fails due to a missing, invalid, or mismatching 724 redirection URI, the authorization server SHOULD inform the resource 725 owner of the error, and MUST NOT redirect the user-agent to the 726 invalid redirection URI. 728 If the resource owner denies the access request or if the request 729 fails for reasons other than a missing or invalid redirection URI, 730 the authorization server informs the client by adding the following 731 parameters to the query component of the redirection URI using the 732 "application/x-www-form-urlencoded" format: 734 error 735 REQUIRED. A single error code from the following: 736 invalid_request 737 The request is missing a required parameter, includes an 738 unsupported parameter or parameter value, or is otherwise 739 malformed. 740 invalid_client 741 The client identifier provided is invalid. 742 unauthorized_client 743 The client is not authorized to request an authorization 744 code using this method. 745 access_denied 746 The resource owner or authorization server denied the 747 request. 748 unsupported_response_type 749 The authorization server does not support obtaining an 750 authorization code using this method. 751 invalid_scope 752 The requested scope is invalid, unknown, or malformed. 753 error_description 754 OPTIONAL. A human-readable text providing additional 755 information, used to assist in the understanding and resolution 756 of the error occurred. 757 error_uri 758 OPTIONAL. A URI identifying a human-readable web page with 759 information about the error, used to provide the resource owner 760 with additional information about the error. 761 state 762 REQUIRED if the "state" parameter was present in the client 763 authorization request. Set to the exact value received from 764 the client. 766 For example, the authorization server redirects the user-agent by 767 sending the following HTTP response: 769 HTTP/1.1 302 Found 770 Location: https://client.example.com/cb?error=access_denied 772 4.1.3. Access Token Request 774 The client makes a request to the token endpoint by adding the 775 following parameter using the "application/x-www-form-urlencoded" 776 format in the HTTP request entity-body: 778 grant_type 779 REQUIRED. Value MUST be set to "authorization_code". 780 code 781 REQUIRED. The authorization code received from the 782 authorization server. 783 redirect_uri 784 REQUIRED. The redirection URI used in the initial request. 786 The client includes its authentication credentials as described in 787 Section 2 789 For example, the client makes the following HTTP request by including 790 its client credentials via the "client_id" and "client_secret" 791 parameters, and using transport-layer security (line breaks are for 792 display purposes only): 794 POST /token HTTP/1.1 795 Host: server.example.com 796 Content-Type: application/x-www-form-urlencoded 798 grant_type=authorization_code&client_id=s6BhdRkqt3& 799 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 800 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 802 The authorization server MUST: 804 o Validate the client credentials and ensure they match the 805 authorization code. 806 o Verify that the authorization code and redirection URI are valid 807 and match its stored association. 809 If the request is valid and authorized, the authorization server 810 issues an access token and optional refresh token, and responds as 811 described in Section 5. 813 4.2. Implicit Grant 815 The implicit grant flow is suitable for clients incapable of 816 maintaining their client credentials confidential (for authenticating 817 with the authorization server) such as client applications residing 818 in a user-agent, typically implemented in a browser using a scripting 819 language such as JavaScript, or native applications. These clients 820 cannot keep client secrets confidential and the authentication of the 821 client is based on the user-agent's same-origin policy. 823 As a redirection-based profile, the client must be capable of 824 interacting with the resource owner's user-agent (typically a web 825 browser) and capable of receiving incoming requests (via redirection) 826 from the authorization server. 828 Unlike the authorization code flow in which the client makes separate 829 requests for authorization and access token, the client receives the 830 access token as the result of the authorization request. 832 The implicit grant flow does not utilize the client credentials since 833 the client is unable to maintain their confidentiality (the client 834 resides on the resource owner's computer or device which makes the 835 client credentials accessible and exploitable). Because the access 836 token is encoded into the redirection URI, it may be exposed to the 837 resource owner and other applications residing on its computer or 838 device. 840 +----------+ 841 | Resource | 842 | Owner | 843 | | 844 +----------+ 845 ^ 846 | 847 (B) 848 +----|-----+ Client Identifier +---------------+ 849 | -+----(A)--- & Redirect URI ----->| | 850 | User- | | Authorization | 851 | Agent -|----(B)-- User authenticates -->| Server | 852 | | | | 853 | |<---(C)---- Redirect URI ------<| | 854 | | with Access Token +---------------+ 855 | | in Fragment 856 | | +---------------+ 857 | |----(D)---- Redirect URI ------>| Web Server | 858 | | without Fragment | with Client | 859 | | | Resource | 860 | (F) |<---(E)------- Script ---------<| | 861 | | +---------------+ 862 +-|--------+ 863 | | 864 (A) (G) Access Token 865 | | 866 ^ v 867 +---------+ 868 | | 869 | Client | 870 | | 871 +---------+ 873 Figure 4: Implicit Grant Flow 875 The flow illustrated in Figure 4 includes the following steps: 877 (A) The client initiates the flow by directing the resource owner's 878 user-agent to the authorization endpoint. The client includes 879 its client identifier, requested scope, local state, and a 880 redirection URI to which the authorization server will send the 881 user-agent back once access is granted (or denied). 882 (B) The authorization server authenticates the resource owner (via 883 the user-agent) and establishes whether the resource owner 884 grants or denies the client's access request. 886 (C) Assuming the resource owner grants access, the authorization 887 server redirects the user-agent back to the client using the 888 redirection URI provided earlier. The redirection URI includes 889 the access token in the URI fragment. 890 (D) The user-agent follows the redirection instructions by making a 891 request to the web server (does not include the fragment). The 892 user-agent retains the fragment information locally. 893 (E) The web server returns a web page (typically an HTML document 894 with an embedded script) capable of accessing the full 895 redirection URI including the fragment retained by the user- 896 agent, and extracting the access token (and other parameters) 897 contained in the fragment. 898 (F) The user-agent executes the script provided by the web server 899 locally, which extracts the access token and passes it to the 900 client. 902 4.2.1. Authorization Request 904 The client constructs the request URI by adding the following 905 parameters to the query component of the authorization endpoint URI 906 using the "application/x-www-form-urlencoded" format: 908 response_type 909 REQUIRED. Value MUST be set to "token". 910 client_id 911 REQUIRED. The client identifier as described in Section 2. 912 Due to lack of client authentication, the client identifier 913 alone MUST NOT be relied upon for client identification. 914 redirect_uri 915 REQUIRED, unless a redirection URI has been established between 916 the client and authorization server via other means. Described 917 in Section 3.1.1. 918 scope 919 OPTIONAL. The scope of the access request expressed as a list 920 of space-delimited strings. The value is defined by the 921 authorization server. If the value contains multiple space- 922 delimited strings, their order does not matter, and each string 923 adds an additional access range to the requested scope. 924 state 925 OPTIONAL. An opaque value used by the client to maintain state 926 between the request and callback. The authorization server 927 includes this value when redirecting the user-agent back to the 928 client. 930 The client directs the resource owner to the constructed URI using an 931 HTTP redirection response, or by other means available to it via the 932 user-agent. 934 For example, the client directs the user-agent to make the following 935 HTTP request using transport-layer security (line breaks are for 936 display purposes only): 938 GET /authorize?response_type=token&client_id=s6BhdRkqt3& 939 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 940 Host: server.example.com 942 The authorization server validates the request to ensure all required 943 parameters are present and valid. If the request is valid, the 944 authorization server authenticates the resource owner and obtains an 945 authorization decision (by asking the resource owner or by 946 establishing approval via other means). 948 When a decision is established, the authorization server directs the 949 user-agent to the provided client redirection URI using an HTTP 950 redirection response, or by other means available to it via the user- 951 agent. 953 4.2.2. Access Token Response 955 If the resource owner grants the access request, the authorization 956 server issues an access token and delivers it to the client by adding 957 the following parameters to the fragment component of the redirection 958 URI using the "application/x-www-form-urlencoded" format: 960 access_token 961 REQUIRED. The access token issued by the authorization server. 962 token_type 963 REQUIRED. The type of the token issued as described in 964 Section 7.1. Value is case insensitive. 965 expires_in 966 OPTIONAL. The duration in seconds of the access token 967 lifetime. For example, the value "3600" denotes that the 968 access token will expire in one hour from the time the response 969 was generated. 970 scope 971 OPTIONAL. The scope of the access request expressed as a list 972 of space-delimited strings. The value is defined by the 973 authorization server. If the value contains multiple space- 974 delimited strings, their order does not matter, and each string 975 adds an additional access range to the requested scope. The 976 authorization server SHOULD include the parameter if the 977 requested scope is different from the one requested by the 978 client. 980 state 981 REQUIRED if the "state" parameter was present in the client 982 authorization request. Set to the exact value received from 983 the client. 985 For example, the authorization server redirects the user-agent by 986 sending the following HTTP response (URI line breaks are for display 987 purposes only): 989 HTTP/1.1 302 Found 990 Location: http://example.com/rd#access_token=FJQbwq9& 991 token_type=example&expires_in=3600 993 The client SHOULD ignore unrecognized response parameters. The 994 access token string size is left undefined by this specification. 995 The client should avoid making assumptions about value sizes. The 996 authorization server should document the size of any value it issues. 998 4.2.2.1. Error Response 1000 If the request fails due to a missing, invalid, or mismatching 1001 redirection URI, the authorization server SHOULD inform the resource 1002 owner of the error, and MUST NOT redirect the user-agent to the 1003 invalid redirection URI. 1005 If the resource owner denies the access request or if the request 1006 fails for reasons other than a missing or invalid redirection URI, 1007 the authorization server informs the client by adding the following 1008 parameters to the fragment component of the redirection URI using the 1009 "application/x-www-form-urlencoded" format: 1011 error 1012 REQUIRED. A single error code from the following: 1013 invalid_request 1014 The request is missing a required parameter, includes an 1015 unsupported parameter or parameter value, or is otherwise 1016 malformed. 1017 invalid_client 1018 The client identifier provided is invalid. 1019 unauthorized_client 1020 The client is not authorized to request an access token 1021 using this method. 1023 access_denied 1024 The resource owner or authorization server denied the 1025 request. 1026 unsupported_response_type 1027 The authorization server does not support obtaining an 1028 access token using this method. 1029 invalid_scope 1030 The requested scope is invalid, unknown, or malformed. 1031 error_description 1032 OPTIONAL. A human-readable text providing additional 1033 information, used to assist in the understanding and resolution 1034 of the error occurred. 1035 error_uri 1036 OPTIONAL. A URI identifying a human-readable web page with 1037 information about the error, used to provide the resource owner 1038 with additional information about the error. 1039 state 1040 REQUIRED if the "state" parameter was present in the client 1041 authorization request. Set to the exact value received from 1042 the client. 1044 For example, the authorization server redirects the user-agent by 1045 sending the following HTTP response: 1047 HTTP/1.1 302 Found 1048 Location: https://client.example.com/cb#error=access_denied 1050 4.3. Resource Owner Password Credentials 1052 The resource owner password credentials flow is suitable in cases 1053 where the resource owner has a trust relationship with the client, 1054 such as its computer operating system or a highly privileged 1055 application. The authorization server should take special care when 1056 enabling the flow, and only when other flows are not viable. 1058 The flow is suitable for clients capable of obtaining the resource 1059 owner credentials (username and password, typically using an 1060 interactive form). It is also used to migrate existing clients using 1061 direct authentication schemes such as HTTP Basic or Digest 1062 authentication to OAuth by converting the stored credentials with an 1063 access token. 1065 The method through which the client obtains the resource owner 1066 credentials is beyond the scope of this specification. The client 1067 MUST discard the credentials once an access token has been obtained. 1069 +----------+ 1070 | Resource | 1071 | Owner | 1072 | | 1073 +----------+ 1074 v 1075 | 1076 (A) Password Credentials 1077 | 1078 v 1079 +---------+ +---------------+ 1080 | | Client Credentials | | 1081 | |>--(B)---- & Resource Owner ----->| | 1082 | Client | Password Credentials | Authorization | 1083 | | | Server | 1084 | |<--(C)---- Access Token ---------<| | 1085 | | (w/ Optional Refresh Token) | | 1086 +---------+ +---------------+ 1088 Figure 5: Resource Owner Password Credentials Flow 1090 The flow illustrated in Figure 5 includes the following steps: 1092 (A) The resource owner provides the client with its username and 1093 password. 1094 (B) The client requests an access token from the authorization 1095 server's token endpoint by authenticating using its client 1096 credentials, and includes the credentials received from the 1097 resource owner. 1098 (C) The authorization server validates the resource owner 1099 credentials and the client credentials and issues an access 1100 token. 1102 4.3.1. Access Token Request 1104 The client makes a request to the token endpoint by adding the 1105 following parameter using the "application/x-www-form-urlencoded" 1106 format in the HTTP request entity-body: 1108 grant_type 1109 REQUIRED. Value MUST be set to "password". 1110 username 1111 REQUIRED. The resource owner username. 1113 password 1114 REQUIRED. The resource owner password. 1115 scope 1116 OPTIONAL. The scope of the access request expressed as a list 1117 of space-delimited strings. The value is defined by the 1118 authorization server. If the value contains multiple space- 1119 delimited strings, their order does not matter, and each string 1120 adds an additional access range to the requested scope. 1122 The client includes its authentication credentials as described in 1123 Section 2 1125 [[ add internationalization consideration for username and password 1126 ]] 1128 For example, the client makes the following HTTP request by including 1129 its client credentials via the "client_id" and "client_secret" 1130 parameters, and using transport-layer security (line breaks are for 1131 display purposes only): 1133 POST /token HTTP/1.1 1134 Host: server.example.com 1135 Content-Type: application/x-www-form-urlencoded 1137 grant_type=password&client_id=s6BhdRkqt3& 1138 client_secret=47HDu8s&username=johndoe&password=A3ddj3w 1140 The authorization server MUST: 1142 o Validate the client credentials. 1143 o Validate the resource owner password credentials. 1145 If the request is valid and authorized, the authorization server 1146 issues an access token and optional refresh token, and responds as 1147 described in Section 5. 1149 4.4. Client Credentials 1151 The client can request an access token using only its client 1152 credentials when the client is requesting access to the protected 1153 resources under its control, or those of another resource owner which 1154 has been previously arranged with the authorization server (the 1155 method of which is beyond the scope of this specification). 1157 +---------+ +---------------+ 1158 | | | | 1159 | |>--(A)--- Client Credentials ---->| Authorization | 1160 | Client | | Server | 1161 | |<--(B)---- Access Token ---------<| | 1162 | | (w/ Optional Refresh Token) | | 1163 +---------+ +---------------+ 1165 Figure 6: Client Credentials Flow 1167 The flow illustrated in Figure 6 includes the following steps: 1169 (A) The client requests an access token from the token endpoint by 1170 authenticating using its client credentials. 1171 (B) The authorization server validates the client credentials and 1172 issues an access token. 1174 4.4.1. Access Token Request 1176 The client makes a request to the token endpoint by adding the 1177 following parameter using the "application/x-www-form-urlencoded" 1178 format in the HTTP request entity-body: 1180 grant_type 1181 REQUIRED. Value MUST be set to "client_credentials". 1182 scope 1183 OPTIONAL. The scope of the access request expressed as a list 1184 of space-delimited strings. The value is defined by the 1185 authorization server. If the value contains multiple space- 1186 delimited strings, their order does not matter, and each string 1187 adds an additional access range to the requested scope. 1189 The client includes its authentication credentials as described in 1190 Section 2 1192 For example, the client makes the following HTTP request by including 1193 its client credentials via the "client_id" and "client_secret" 1194 parameters, and using transport-layer security (line breaks are for 1195 display purposes only): 1197 POST /token HTTP/1.1 1198 Host: server.example.com 1199 Content-Type: application/x-www-form-urlencoded 1201 grant_type=client_credentials&client_id=s6BhdRkqt3& 1202 client_secret=47HDu8s 1204 The authorization server MUST validate the client credentials. 1206 If the request is valid and authorized, the authorization server 1207 issues an access token and optional refresh token, and responds as 1208 described in Section 5. 1210 4.5. Extensions 1212 The client uses an extension grant type by specifying the grant type 1213 using an absolute URI (defined by the authorization server) as the 1214 value of the "grant_type" parameter of the token endpoint, and by 1215 adding any additional parameters necessary. 1217 For example, to request an access token using a SAML 2.0 assertion 1218 grant type, the client makes the following HTTP request using 1219 transport-layer security (line breaks are for display purposes only): 1221 POST /token HTTP/1.1 1222 Host: server.example.com 1223 Content-Type: application/x-www-form-urlencoded 1225 grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F 1226 saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ 1227 [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 1229 Client authentication and the scope of the grant are obtained via the 1230 assertion as defined by [I-D.ietf-oauth-saml2-bearer]. 1232 5. Issuing an Access Token 1234 If the access token request is valid and authorized, the 1235 authorization server issues an access token and optional refresh 1236 token as described in Section 5.1. If the request failed client 1237 authentication or is invalid, the authorization server return an 1238 error response as described in Section 5.2. 1240 5.1. Successful Response 1242 The authorization server issues an access token and optional refresh 1243 token, and constructs the response by adding the following parameters 1244 to the entity body of the HTTP response with a 200 (OK) status code: 1246 access_token 1247 REQUIRED. The access token issued by the authorization server. 1248 token_type 1249 REQUIRED. The type of the token issued as described in 1250 Section 7.1. Value is case insensitive. 1251 expires_in 1252 OPTIONAL. The duration in seconds of the access token 1253 lifetime. For example, the value "3600" denotes that the 1254 access token will expire in one hour from the time the response 1255 was generated. 1256 refresh_token 1257 OPTIONAL. The refresh token which can be used to obtain new 1258 access tokens using the same authorization grant as described 1259 in Section 6. 1260 scope 1261 OPTIONAL. The scope of the access request expressed as a list 1262 of space-delimited strings. The value is defined by the 1263 authorization server. If the value contains multiple space- 1264 delimited strings, their order does not matter, and each string 1265 adds an additional access range to the requested scope. The 1266 authorization server SHOULD include the parameter if the 1267 requested scope is different from the one requested by the 1268 client. 1270 The parameters are including in the entity body of the HTTP response 1271 using the "application/json" media type as defined by [RFC4627]. The 1272 parameters are serialized into a JSON structure by adding each 1273 parameter at the highest structure level. Parameter names and string 1274 values are included as JSON strings. Numerical values are included 1275 as JSON numbers. 1277 The authorization server MUST include the HTTP "Cache-Control" 1278 response header field with a value of "no-store" in any response 1279 containing tokens, secrets, or other sensitive information. 1281 For example: 1283 HTTP/1.1 200 OK 1284 Content-Type: application/json 1285 Cache-Control: no-store 1287 { 1288 "access_token":"SlAV32hkKG", 1289 "token_type":"example", 1290 "expires_in":3600, 1291 "refresh_token":"8xLOxBtZp8", 1292 "example_parameter":"example-value" 1294 } 1296 The client SHOULD ignore unrecognized response parameters. The sizes 1297 of tokens and other values received from the authorization server are 1298 left undefined. The client should avoid making assumptions about 1299 value sizes. The authorization server should document the size of 1300 any value it issues. 1302 5.2. Error Response 1304 If the client provided invalid credentials using an HTTP 1305 authentication scheme via the "Authorization" request header field, 1306 the authorization server MUST respond with a HTTP 401 (Unauthorized) 1307 status code, and include the "WWW-Authenticate" response header field 1308 matching the authentication scheme used by the client. Otherwise, 1309 the authorization server MUST respond with the HTTP 400 (Bad Request) 1310 status code. 1312 The authorization server constructs the response by adding the 1313 following parameter to the response: 1315 error 1316 REQUIRED. A single error code from the following: 1317 invalid_request 1318 The request is missing a required parameter, includes an 1319 unsupported parameter or parameter value, repeats a 1320 parameter, includes multiple credentials, utilizes more 1321 than one mechanism for authenticating the client, or is 1322 otherwise malformed. 1323 invalid_client 1324 Client authentication failed (e.g. unknown client, no 1325 client credentials included, multiple client credentials 1326 included, or unsupported credentials type). 1327 invalid_grant 1328 The provided authorization grant is invalid, expired, 1329 revoked, or does not match the redirection URI used in 1330 the authorization request. 1331 unauthorized_client 1332 The authenticated client is not authorized to use this 1333 authorization grant type. 1334 unsupported_grant_type 1335 The authorization grant type is not supported by the 1336 authorization server. 1338 invalid_scope 1339 The requested scope is invalid, unknown, malformed, or 1340 exceeds the previously granted scope. 1341 error_description 1342 OPTIONAL. A human-readable text providing additional 1343 information, used to assist in the understanding and resolution 1344 of the error occurred. 1345 error_uri 1346 OPTIONAL. A URI identifying a human-readable web page with 1347 information about the error, used to provide the resource owner 1348 with additional information about the error. 1350 The parameters are including in the entity body of the HTTP response 1351 using the "application/json" media type as defined by [RFC4627]. The 1352 parameters are serialized into a JSON structure by adding each 1353 parameter at the highest structure level. Parameter names and string 1354 values are included as JSON strings. Numerical values are included 1355 as JSON numbers. 1357 For example: 1359 HTTP/1.1 400 Bad Request 1360 Content-Type: application/json 1361 Cache-Control: no-store 1363 { 1364 "error":"invalid_request" 1365 } 1367 6. Refreshing an Access Token 1369 The client makes a request to the token endpoint by adding the 1370 following parameter using the "application/x-www-form-urlencoded" 1371 format in the HTTP request entity-body: 1373 grant_type 1374 REQUIRED. Value MUST be set to "refresh_token". 1375 refresh_token 1376 REQUIRED. The refresh token issued along the access token 1377 being refreshed. 1378 scope 1379 OPTIONAL. The scope of the access request expressed as a list 1380 of space-delimited strings. The value is defined by the 1381 authorization server. If the value contains multiple space- 1382 delimited strings, their order does not matter, and each string 1383 adds an additional access range to the requested scope. The 1384 requested scope MUST be equal or lesser than the scope 1385 originally granted by the resource owner, and if omitted is 1386 treated as equal to the previously approved scope. 1388 The client includes its authentication credentials as described in 1389 Section 2 1391 For example, the client makes the following HTTP request by including 1392 its client credentials via the "client_id" and "client_secret" 1393 parameters, and using transport-layer security (line breaks are for 1394 display purposes only): 1396 POST /token HTTP/1.1 1397 Host: server.example.com 1398 Content-Type: application/x-www-form-urlencoded 1400 grant_type=refresh_token&client_id=s6BhdRkqt3& 1401 client_secret=8eSEIpnqmM&refresh_token=n4E9O119d 1403 The authorization server MUST validate the client credentials, the 1404 refresh token, and verify that the resource owner's authorization is 1405 still valid. If valid, the authorization server issues an access 1406 token response as described in Section 5. 1408 The authorization server MAY issue a new refresh token, in which 1409 case, the client MUST discard the old refresh token and replace it 1410 with the new refresh token. 1412 7. Accessing Protected Resources 1414 The client accesses protected resources by presenting the access 1415 token to the resource server. The resource server MUST validate the 1416 access token and ensure it has not expired and that its scope covers 1417 the requested resource. The methods used by the resource server to 1418 validate the access token are beyond the scope of this specification, 1419 but generally involve an interaction or coordination between the 1420 resource server and the authorization server. 1422 The method in which the client utilized the access token to 1423 authenticate with the resource server depends on the type of access 1424 token issued by the authorization server. Typically, it involves 1425 using the HTTP "Authorization" request header field with an 1426 authentication scheme defined by the access token type specification. 1428 7.1. Access Token Types 1430 The access token type provides the client with the information 1431 required to successfully utilize the access token to make a protected 1432 resource request (along with type-specific attributes). 1434 For example, the "bearer" token type defined in 1435 [I-D.ietf-oauth-v2-bearer] is utilized by simply including the access 1436 token string in the request: 1438 GET /resource/1 HTTP/1.1 1439 Host: example.com 1440 Authorization: BEARER h480djs93hd8 1442 while the "mac" token type defined in [I-D.hammer-oauth-v2-mac-token] 1443 is utilized by issuing a token secret together with the access token 1444 which is used to sign certain components of the HTTP requests: 1446 GET /resource/1 HTTP/1.1 1447 Host: example.com 1448 Authorization: MAC token="h480djs93hd8", 1449 timestamp="137131200", 1450 nonce="dj83hs9s", 1451 signature="kDZvddkndxvhGRXZhvuDjEWhGeE=" 1453 Each access token type definition specifies the additional attributes 1454 (if any) sent to the client together with the "access_token" response 1455 parameter. It also defines the HTTP authentication method used to 1456 include the access token when making a protected resource request. 1458 8. Extensibility 1460 8.1. Defining Access Token Types 1462 Access token types can be defined in one of two ways: registered in 1463 the access token type registry (following the procedures in 1464 Section 10.1), or use the "x_" type name prefix. 1466 Types utilizing the "x_" name prefix MUST be limited to vendor- 1467 specific implementations that are not commonly applicable, and are 1468 specific to the implementation details of the resource server where 1469 they are used. If a vendor-specific type requires additional vendor- 1470 specific token response parameters, they MUST also use the "x_" name 1471 prefix. 1473 All other types MUST be registered, and MUST NOT use the "x_" type 1474 name prefix. Type names MUST conform to the type-name ABNF. If the 1475 type definition includes a new HTTP authentication scheme, the type 1476 name SHOULD be identical to the authentication scheme name (as 1477 defined by [RFC2617]). 1479 type-name = 1*name-char 1480 name-char = "-" / "." / "_" / DIGIT / ALPHA 1482 8.2. Defining New Endpoint Parameters 1484 New request or response parameters for use with the authorization 1485 endpoint or the token endpoint can be added in one of two ways: 1486 registered in the parameters registry (following the procedures in 1487 Section 10.2), or use the "x_" parameter name prefix. 1489 Parameters utilizing the "x_" parameter name prefix MUST be limited 1490 to vendor-specific extensions that are not commonly applicable, and 1491 are specific to the implementation details of the authorization 1492 server where they are used. All other new parameters MUST be 1493 registered, and MUST NOT use the "x_" parameter name prefix. 1495 Parameter names MUST conform to the param-name ABNF, and parameter 1496 values syntax MUST be well-defined (e.g., using ABNF, or a reference 1497 to the syntax of an existing parameter). 1499 param-name = 1*name-char 1500 name-char = "-" / "." / "_" / DIGIT / ALPHA 1502 8.3. Defining New Authorization Grant Types 1504 New authorization grant types can be defined by assigning them a 1505 unique URI for use with the "grant_type" parameter. If the extension 1506 grant type requires additional token endpoint parameters, they MUST 1507 be registered in the OAuth parameters registry as described by 1508 Section 10.2. 1510 9. Security Considerations 1512 [[ TBD ]] 1514 10. IANA Considerations 1516 10.1. The OAuth Access Token Type Registry 1518 This specification establishes the OAuth access token type registry. 1520 Access token types are registered on the advice of one or more 1521 Designated Experts (appointed by the IESG or their delegate), with a 1522 Specification Required (using terminology from [RFC5226]). However, 1523 to allow for the allocation of values prior to publication, the 1524 Designated Expert(s) may approve registration once they are satisfied 1525 that such a specification will be published. 1527 Registration requests should be sent to the [TBD]@ietf.org mailing 1528 list for review and comment, with an appropriate subject (e.g., 1529 "Request for access toke type: example"). [[ Note to RFC-EDITOR: The 1530 name of the mailing list should be determined in consultation with 1531 the IESG and IANA. Suggested name: oauth-ext-review. ]] 1533 Before a period of 14 days has passed, the Designated Expert(s) will 1534 either approve or deny the registration request, communicating this 1535 decision both to the review list and to IANA. Denials should include 1536 an explanation and, if applicable, suggestions as to how to make the 1537 request successful. Registration requests that are undetermined for 1538 a period longer than 21 days can be brought to the IESG's attention 1539 (using the iesg@iesg.org mailing list) for resolution. 1541 10.1.1. Registration Template 1543 Type name: 1544 The name requested (e.g., "example"). 1545 Additional Token Endpoint Response Parameters: 1546 Additional response parameters returned together with the 1547 "access_token" parameter. New parameters MUST be separately 1548 registered in the OAuth parameters registry as described by 1549 Section 10.2. 1550 HTTP Authentication Scheme(s): 1551 The HTTP authentication scheme name(s), if any, used to 1552 authenticate protected resources requests using access token of 1553 this type. 1554 Change controller: 1555 For standards-track RFCs, state "IETF". For others, give the name 1556 of the responsible party. Other details (e.g., postal address, 1557 e-mail address, home page URI) may also be included. 1559 Specification document(s): 1560 Reference to document that specifies the parameter, preferably 1561 including a URI that can be used to retrieve a copy of the 1562 document. An indication of the relevant sections may also be 1563 included, but is not required. 1565 10.2. The OAuth Parameters Registry 1567 This specification establishes the OAuth parameters registry. 1569 Additional parameters for inclusion in the authorization endpoint 1570 request, the authorization endpoint response, the token endpoint 1571 request, or the token endpoint response, are registered on the advice 1572 of one or more Designated Experts (appointed by the IESG or their 1573 delegate), with a Specification Required (using terminology from 1574 [RFC5226]). However, to allow for the allocation of values prior to 1575 publication, the Designated Expert(s) may approve registration once 1576 they are satisfied that such a specification will be published. 1578 Registration requests should be sent to the [TBD]@ietf.org mailing 1579 list for review and comment, with an appropriate subject (e.g., 1580 "Request for parameter: example"). [[ Note to RFC-EDITOR: The name of 1581 the mailing list should be determined in consultation with the IESG 1582 and IANA. Suggested name: oauth-ext-review. ]] 1584 Before a period of 14 days has passed, the Designated Expert(s) will 1585 either approve or deny the registration request, communicating this 1586 decision both to the review list and to IANA. Denials should include 1587 an explanation and, if applicable, suggestions as to how to make the 1588 request successful. Registration requests that are undetermined for 1589 a period longer than 21 days can be brought to the IESG's attention 1590 (using the iesg@iesg.org mailing list) for resolution. 1592 10.2.1. Registration Template 1594 Parameter name: 1595 The name requested (e.g., "example"). 1596 Parameter usage location: 1597 The location(s) where parameter can be used. The possible 1598 locations are: authorization request, authorization response, 1599 token request, or token response. 1600 Change controller: 1601 For standards-track RFCs, state "IETF". For others, give the name 1602 of the responsible party. Other details (e.g., postal address, 1603 e-mail address, home page URI) may also be included. 1605 Specification document(s): 1606 Reference to document that specifies the parameter, preferably 1607 including a URI that can be used to retrieve a copy of the 1608 document. An indication of the relevant sections may also be 1609 included, but is not required. 1611 10.2.2. Initial Registry Contents 1613 The OAuth Parameters Registry's initial contents are: 1615 o Parameter name: client_id 1616 o Parameter usage location: authorization request, token request 1617 o Change controller: IETF 1618 o Specification document(s): [[ this document ]] 1620 o Parameter name: client_secret 1621 o Parameter usage location: token request 1622 o Change controller: IETF 1623 o Specification document(s): [[ this document ]] 1625 o Parameter name: response_type 1626 o Parameter usage location: authorization request 1627 o Change controller: IETF 1628 o Specification document(s): [[ this document ]] 1630 o Parameter name: redirect_uri 1631 o Parameter usage location: authorization request, token request 1632 o Change controller: IETF 1633 o Specification document(s): [[ this document ]] 1635 o Parameter name: scope 1636 o Parameter usage location: authorization request, authorization 1637 response, token request, token response 1638 o Change controller: IETF 1639 o Specification document(s): [[ this document ]] 1641 o Parameter name: state 1642 o Parameter usage location: authorization request, authorization 1643 response 1644 o Change controller: IETF 1645 o Specification document(s): [[ this document ]] 1647 o Parameter name: code 1648 o Parameter usage location: authorization response, token request 1649 o Change controller: IETF 1650 o Specification document(s): [[ this document ]] 1651 o Parameter name: error_description 1652 o Parameter usage location: authorization response, token response 1653 o Change controller: IETF 1654 o Specification document(s): [[ this document ]] 1656 o Parameter name: error_uri 1657 o Parameter usage location: authorization response, token response 1658 o Change controller: IETF 1659 o Specification document(s): [[ this document ]] 1661 o Parameter name: grant_type 1662 o Parameter usage location: token request 1663 o Change controller: IETF 1664 o Specification document(s): [[ this document ]] 1666 o Parameter name: access_token 1667 o Parameter usage location: authorization response, token response 1668 o Change controller: IETF 1669 o Specification document(s): [[ this document ]] 1671 o Parameter name: token_type 1672 o Parameter usage location: authorization response, token response 1673 o Change controller: IETF 1674 o Specification document(s): [[ this document ]] 1676 o Parameter name: expires_in 1677 o Parameter usage location: authorization response, token response 1678 o Change controller: IETF 1679 o Specification document(s): [[ this document ]] 1681 o Parameter name: username 1682 o Parameter usage location: token request 1683 o Change controller: IETF 1684 o Specification document(s): [[ this document ]] 1686 o Parameter name: password 1687 o Parameter usage location: token request 1688 o Change controller: IETF 1689 o Specification document(s): [[ this document ]] 1691 o Parameter name: refresh_token 1692 o Parameter usage location: token request, token response 1693 o Change controller: IETF 1694 o Specification document(s): [[ this document ]] 1696 Appendix A. Examples 1698 [[ TBD ]] 1700 Appendix B. Contributors 1702 The following people contributed to preliminary versions of this 1703 document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland 1704 (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), 1705 Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and 1706 concepts within are a product of the OAuth community, WRAP community, 1707 and the OAuth Working Group. 1709 The OAuth Working Group has dozens of very active contributors who 1710 proposed ideas and wording for this document, including: 1712 Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah 1713 Culver, Bill de hOra, Brian Ellin, Igor Faynberg, George Fletcher, 1714 Tim Freeman, Evan Gilbert, Kristoffer Gronowski, Justin Hart, Phil 1715 Hunt, Mike Jones, John Kemp, Chasen Le Hara, Torsten Lodderstedt, 1716 Alastair Mair, Eve Maler, James Manger, Laurence Miao, Chuck 1717 Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, 1718 Marius Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian 1719 Stuebner, Paul Tarjan, Franklin Tse, and Nick Walker. 1721 Appendix C. Acknowledgements 1723 [[ Add OAuth 1.0a authors + WG contributors ]] 1725 Appendix D. Document History 1727 [[ to be removed by RFC editor before publication as an RFC ]] 1729 -12 1731 o Complete restructure with lots of new prose. 1732 o Removed terminology and expanded terms in overview. 1733 o Changed assertions to extensions and added informative reference 1734 to the SAML 2.0 extension. 1735 o Renamed access grant to authorization grant. 1736 o Clarified 'token_type' as case insensitive. 1737 o Authorization endpoint requires TLS when an access token is 1738 issued. 1740 o Removed client assertion credentials, mandatory HTTP Basic 1741 authentication support for client credentials, WWW-Authenticate 1742 header, and the OAuth2 authentication scheme. 1743 o Changed implicit grant (aka user-agent flow) error response from 1744 query to fragment. 1745 o Removed the 'redirect_uri_mismatch' error code since in such a 1746 case, the authorization server must not send the error back to the 1747 client. 1748 o Added parameter registration for all parameters in this 1749 specification. 1750 o Defined access token type registry. 1752 -11 1754 o Many editorial changes. Fixed user authorization section 1755 structure. Removed unused normative references. Adjusted 1756 language regarding single use of authorization codes. 1757 o Fixed header ABNF. 1758 o Change access token description from shared symmetric secret to 1759 password. 1760 o Moved access grant 'none' to a separate section, renamed to 1761 'client_credentials'. 1762 o Demoted the HTTP status code requirement from MUST to SHOULD in 1763 protected resource response error. 1764 o Removed 'expired_token' error code. 1765 o Moved all the 'code_and_token' parameter to the fragment (from 1766 code being in the query). 1767 o Removed 'assertion_type' parameter (moved to 'grant_type'). 1768 o Added note about redirecting to invalid redirection URIs (open 1769 redirectors). 1770 o Removed bearer token section, added new required 'token_type' 1771 parameter with extensibility. 1772 o 'error-uri' parameter value changed to absolute URI. 1773 o OAuth 2.0 HTTP authentication scheme name changed to 'OAuth2'. 1774 o Dropped the 'WWW-Authenticate' header field 'realm' parameter. 1775 o Removed definition of access token characters. 1776 o Added instructions for dealing with error and an invalid 1777 redirection URI. 1779 -10 1781 o Fixed typos. Many editorial changes. Rewrote introduction. 1782 removed terminology grouping. 1783 o Allowed POST for resource owner authorization endpoint. 1784 o Fixed token endpoint to not require client authentication. 1785 o Made URI query and POST body 'oauth_token' parameter optional. 1787 o Moved all parameter names and values to use underscores. 1788 o Changed 'basic_credentials' to 'password', 1789 'invalid_client_credentials' and 'invalid_client_id' to 1790 'invalid_client'. 1791 o Added note that access token requests without an access grant 1792 should not include a refresh token. 1793 o Changed scheme name from 'Token' to 'OAuth', simplified request 1794 format to simple string for token instead of key=value pair (still 1795 supported for extensions). 1796 o Defined permitted access token string characters (suitable for 1797 inclusion in an HTTP header). 1798 o Added a note about conflicts with previous versions. 1799 o Moved 'client_id' definition from client authentication to access 1800 token endpoint. 1801 o Added definition for 'access grant'. 1803 -09 1805 o Fixed typos, editorial changes. 1806 o Added token expiration example. 1807 o Added scope parameter to resource owner authorization endpoint 1808 response. 1809 o Added note about parameters with empty values (same as omitted). 1810 o Changed parameter values to use '-' instead of '_'. Parameter 1811 names still use '_'. 1812 o Changed authorization endpoint client type to response type with 1813 values: code, token, and both. 1814 o Complete cleanup of error codes. Added support for error 1815 description and URI. 1816 o Add initial extensibility support. 1818 -08 1820 o Renamed verification code to authorization code. 1821 o Revised terminology, structured section, added new terms. 1822 o Changed flows to profiles and moved to introduction. 1823 o Added support for access token rescoping. 1824 o Cleaned up client credentials section. 1825 o New introduction overview. 1826 o Added error code for invalid username and password, and renamed 1827 error code to be more consistent. 1828 o Added access grant type parameter to token endpoint. 1830 -07 1832 o Major rewrite of entire document structure. 1834 o Removed device profile. 1835 o Added verification code support to user-agent flow. 1836 o Removed multiple formats support, leaving JSON as the only format. 1837 o Changed assertion "assertion_format" parameter to 1838 "assertion_type". 1839 o Removed "type" parameter from token endpoint. 1841 -06 1843 o Editorial changes, corrections, clarifications, etc. 1844 o Removed conformance section. 1845 o Moved authors section to contributors appendix. 1846 o Added section on native applications. 1847 o Changed error response to use the requested format. Added support 1848 for HTTP "Accept" header. 1849 o Flipped the order of the web server and user-agent flows. 1850 o Renamed assertion flow "format" parameter name to 1851 "assertion_format" to resolve conflict. 1852 o Removed the term identifier from token definitions. Added a 1853 cryptographic token definition. 1854 o Added figure titles. 1855 o Added server response 401 when client tried to authenticate using 1856 multiple credentials. 1857 o Clarified support for TLS alternatives, and added requirement for 1858 TLS 1.2 support for token endpoint. 1859 o Removed all signature and cryptography. 1860 o Removed all discovery. 1861 o Updated HTML4 reference. 1863 -05 1865 o Corrected device example. 1866 o Added client credentials parameters to the assertion flow as 1867 OPTIONAL. 1868 o Added the ability to send client credentials using an HTTP 1869 authentication scheme. 1870 o Initial text for the "WWW-Authenticate" header (also added scope 1871 support). 1872 o Change authorization endpoint to resource owner endpoint. 1873 o In the device flow, change the "user_uri" parameter to 1874 "verification_uri" to avoid confusion with the resource owner 1875 endpoint. 1876 o Add "format" request parameter and support for XML and form- 1877 encoded responses. 1879 -04 1880 o Changed all token endpoints to use "POST" 1881 o Clarified the authorization server's ability to issue a new 1882 refresh token when refreshing a token. 1883 o Changed the flow categories to clarify the autonomous group. 1884 o Changed client credentials language not to always be server- 1885 issued. 1886 o Added a "scope" response parameter. 1887 o Fixed typos. 1888 o Fixed broken document structure. 1890 -03 1892 o Fixed typo in JSON error examples. 1893 o Fixed general typos. 1894 o Moved all flows sections up one level. 1896 -02 1898 o Removed restriction on "redirect_uri" including a query. 1899 o Added "scope" parameter. 1900 o Initial proposal for a JSON-based token response format. 1902 -01 1904 o Editorial changes based on feedback from Brian Eaton, Bill Keenan, 1905 and Chuck Mortimore. 1906 o Changed device flow "type" parameter values and switch to use only 1907 the token endpoint. 1909 -00 1911 o Initial draft based on a combination of WRAP and OAuth 1.0a. 1913 11. References 1915 11.1. Normative References 1917 [I-D.ietf-httpbis-p1-messaging] 1918 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1919 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 1920 "HTTP/1.1, part 1: URIs, Connections, and Message 1921 Parsing", draft-ietf-httpbis-p1-messaging-09 (work in 1922 progress), March 2010. 1924 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1925 Extensions (MIME) Part One: Format of Internet Message 1926 Bodies", RFC 2045, November 1996. 1928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1929 Requirement Levels", BCP 14, RFC 2119, March 1997. 1931 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1932 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1933 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1935 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1936 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1937 Authentication: Basic and Digest Access Authentication", 1938 RFC 2617, June 1999. 1940 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1942 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, 1943 May 2000. 1945 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1946 Types", RFC 3023, January 2001. 1948 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1949 Standards (PKCS) #1: RSA Cryptography Specifications 1950 Version 2.1", RFC 3447, February 2003. 1952 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1953 10646", STD 63, RFC 3629, November 2003. 1955 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1956 Resource Identifier (URI): Generic Syntax", STD 66, 1957 RFC 3986, January 2005. 1959 [RFC4627] Crockford, D., "The application/json Media Type for 1960 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1962 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1963 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1964 May 2008. 1966 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1967 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1969 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1970 April 2010. 1972 [W3C.REC-html401-19991224] 1973 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1974 Specification", World Wide Web Consortium 1975 Recommendation REC-html401-19991224, December 1999, 1976 . 1978 11.2. Informative References 1980 [I-D.hammer-oauth-v2-mac-token] 1981 Hammer-Lahav, E., "HTTP Authentication: MAC 1982 Authentication", draft-hammer-oauth-v2-mac-token-01 (work 1983 in progress), January 2011. 1985 [I-D.ietf-oauth-saml2-bearer] 1986 Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion 1987 Grant Type Profile for OAuth 2.0", 1988 draft-ietf-oauth-saml2-bearer-00 (work in progress), 1989 December 2010. 1991 [I-D.ietf-oauth-v2-bearer] 1992 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 1993 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-01 1994 (work in progress), December 2010. 1996 [OASIS.saml-core-2.0-os] 1997 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1998 "Assertions and Protocol for the OASIS Security Assertion 1999 Markup Language (SAML) V2.0", OASIS Standard saml-core- 2000 2.0-os, March 2005. 2002 Authors' Addresses 2004 Eran Hammer-Lahav (editor) 2005 Yahoo! 2007 Email: eran@hueniverse.com 2008 URI: http://hueniverse.com 2010 David Recordon 2011 Facebook 2013 Email: dr@fb.com 2014 URI: http://www.davidrecordon.com/ 2015 Dick Hardt 2016 Microsoft 2018 Email: dick.hardt@gmail.com 2019 URI: http://dickhardt.org/