idnits 2.17.1 draft-ietf-oauth-v2-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 15, 2010) is 5035 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: 'NIST FIPS-180-3' is defined on line 1373, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1377, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 1399, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 1402, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'I-D.hammer-oauth' is defined on line 1427, but no explicit reference was found in the text == Unused Reference: 'I-D.hardt-oauth' is defined on line 1431, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST FIPS-180-3' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** 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 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 5246 (Obsoleted by RFC 8446) Summary: 8 errors (**), 0 flaws (~~), 11 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 Intended status: Standards Track D. Recordon 5 Expires: December 17, 2010 Facebook 6 D. Hardt 7 Microsoft 8 June 15, 2010 10 The OAuth 2.0 Protocol 11 draft-ietf-oauth-v2-08 13 Abstract 15 This specification describes the OAuth 2.0 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 December 17, 2010. 34 Copyright Notice 36 Copyright (c) 2010 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. Notational Conventions . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.4. Client Profiles . . . . . . . . . . . . . . . . . . . . . 8 56 1.4.1. Web Server . . . . . . . . . . . . . . . . . . . . . . 8 57 1.4.2. User-Agent . . . . . . . . . . . . . . . . . . . . . . 9 58 1.4.3. Native Application . . . . . . . . . . . . . . . . . . 11 59 1.4.4. Autonomous . . . . . . . . . . . . . . . . . . . . . . 12 60 2. Client Credentials . . . . . . . . . . . . . . . . . . . . . . 12 61 2.1. Basic Client Credentials . . . . . . . . . . . . . . . . . 13 62 3. Obtaining End-User Authorization . . . . . . . . . . . . . . . 14 63 3.1. Authorization Server Response . . . . . . . . . . . . . . 16 64 4. Obtaining an Access Token . . . . . . . . . . . . . . . . . . 17 65 4.1. Access Grant Parameters . . . . . . . . . . . . . . . . . 18 66 4.1.1. Authorization Code . . . . . . . . . . . . . . . . . . 18 67 4.1.2. Resource Owner Basic Credentials . . . . . . . . . . . 19 68 4.1.3. Assertion . . . . . . . . . . . . . . . . . . . . . . 20 69 4.1.4. Refresh Token . . . . . . . . . . . . . . . . . . . . 20 70 4.2. Access Token Response . . . . . . . . . . . . . . . . . . 21 71 4.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 22 72 4.3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 23 73 5. Accessing a Protected Resource . . . . . . . . . . . . . . . . 23 74 5.1. The Authorization Request Header Field . . . . . . . . . . 24 75 5.2. URI Query Parameter . . . . . . . . . . . . . . . . . . . 25 76 5.3. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 25 77 6. The WWW-Authenticate Response Header Field . . . . . . . . . . 26 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27 81 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 27 82 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 28 83 Appendix D. Document History . . . . . . . . . . . . . . . . . . 28 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 89 1. Introduction 91 With the increasing use of distributed web services and cloud 92 computing, third-party applications require access to server-hosted 93 resources. These resources are usually protected and require 94 authentication using the resource owner's credentials (typically a 95 username and password). In the traditional client-server 96 authentication model, a client accessing a protected resource on a 97 server presents the resource owner's credentials in order to 98 authenticate and gain access. 100 OAuth introduces a third role to the traditional client-server 101 authentication model: the resource owner. In OAuth, the client 102 (which is usually not the resource owner, but is acting on its 103 behalf) requests access to resources controlled by the resource owner 104 and hosted by the resource server. 106 In addition to removing the need for resource owners to share their 107 credentials, resource owners should also have the ability to restrict 108 access to a limited subset of the resources they control, to limit 109 access duration, or to limit access to the methods supported by these 110 resources. 112 Instead of using the resource owner's credentials to access protected 113 resources, clients obtain an access token (which denotes a specific 114 scope, duration, and other attributes). Tokens are issued to third- 115 party client by an authorization server with the approval of the 116 resource owner. The client uses the access token to access the 117 protected resources. 119 For example, a web user (resource owner) can grant a printing service 120 (client) access to her protected photos stored at a photo sharing 121 service (resource server), without sharing her username and password 122 with the printing service. Instead, she authenticates directly with 123 the photo sharing service (authorization server) which issues the 124 printing service delegation-specific credentials (token). 126 This specification defines the use of OAuth over HTTP [RFC2616] (or 127 HTTP over TLS as defined by [RFC2818]). Other specifications may 128 extend it for use with other transport protocols. 130 1.1. Notational Conventions 132 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 133 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 134 document are to be interpreted as described in [RFC2119]. 136 This document uses the Augmented Backus-Naur Form (ABNF) notation of 138 [I-D.ietf-httpbis-p1-messaging]. Additionally, the realm and auth- 139 param rules are included from [RFC2617]. 141 Unless otherwise noted, all the protocol parameter names and values 142 are case sensitive. 144 1.2. Terminology 146 protected resource 147 An access-restricted resource which can be obtained using an 148 OAuth-authenticated request. 150 resource server 151 A server capable of accepting and responding to protected 152 resource requests. 154 client 155 An application obtaining authorization and making protected 156 resource requests. 158 resource owner 159 An entity capable of granting access to a protected resource. 161 end-user 162 A human resource owner. 164 token 165 A string representing an access authorization issued to the 166 client. The string is usually opaque to the client and can 167 self-contain the authorization information in a verifiable 168 manner (i.e. signed), or denotes an identifier used to retrieve 169 the information. Tokens represent a specific scope, duration, 170 and other authorization attributes granted by the resource 171 owner and enforced by the resource server and authorization 172 servers. 174 access token 175 A token used by the client to make authenticated requests 176 on behalf of the resource owner. 178 refresh token 179 A token used by the client to obtain a new access token 180 (in addition or as a replacement for an expired access 181 token), without having to involve the resource owner. 183 authorization code A short-lived token representing the access 184 grant provided by the end-user. The authorization code 185 is used to obtain an access token and a refresh token. 187 authorization server 188 A server capable of issuing tokens after successfully 189 authenticating the resource owner and obtaining authorization. 190 The authorization server may be the same server as the resource 191 server, or a separate entity. 193 end-user authorization endpoint 194 The authorization server's HTTP endpoint capable of 195 authenticating the end-user and obtaining authorization. The 196 end-user authorization endpoint is described in Section 3. 198 token endpoint 199 The authorization server's HTTP endpoint capable of issuing 200 tokens and refreshing expired tokens. The token endpoint is 201 described in Section 4. 203 client identifier 204 An unique identifier issued to the client to identify itself to 205 the authorization server. Client identifiers may have a 206 matching secret. The client identifier is described in 207 Section 2. 209 1.3. Overview 211 OAuth provides a method for clients to access a protected resource on 212 behalf of a resource owner. Before a client can access a protected 213 resource, it must first obtain authorization from the resource owner, 214 then exchange that access grant for an access token (representing the 215 grant's scope, duration, and other attributes). The client accesses 216 the protected resource by presenting the access token to the resource 217 server. 219 +--------+ +---------------+ 220 | |--(A)-- Authorization Request --->| Resource | 221 | | | Owner | 222 | |<-(B)------ Access Grant ---------| | 223 | | +---------------+ 224 | | 225 | | Client Credentials & +---------------+ 226 | |--(C)------ Access Grant -------->| Authorization | 227 | Client | | Server | 228 | |<-(D)------ Access Token ---------| | 229 | | (w/ Optional Refresh Token) +---------------+ 230 | | 231 | | +---------------+ 232 | |--(E)------ Access Token -------->| Resource | 233 | | | Server | 234 | |<-(F)---- Protected Resource -----| | 235 +--------+ +---------------+ 237 Figure 1: Abstract Protocol Flow 239 The abstract flow illustrated in Figure 1 includes the following 240 steps: 242 (A) The client requests authorization from the resource owner. The 243 client should not interact directly with the resource owner 244 (since that would exposing the resource owner's credentials to 245 the client), but instead requests authorization via an 246 authorization server or other entities. For example, the client 247 directs the resource owner to the authorization server which in 248 turn issues it an access grant. When cannot be avoided, the 249 client interacts directly with the end-user, asking for the end- 250 user's username and password. 252 (B) The client is issued an access grant which represents the 253 authorization provided by the resource owner. The access grant 254 can be expressed as: 256 * Authorization code - an access grant obtained via an 257 authorization server. The process used to obtain an 258 authorization code is described in Section 3. 260 * Assertion - an access grant obtained from entities using a 261 different trust framework. Assertions enable the client to 262 utilize existing trust relationships to obtain an access 263 token. They provide a bridge between OAuth and other trust 264 frameworks. The access grant represented by an assertion 265 depends on the assertion type, its content, and how it was 266 issued, which are beyond the scope of this specification. 268 * Basic end-user credentials - obtained when interacting 269 directly with an end-user. Resource owner credentials should 270 only be used when there is a high degree of trust between the 271 resource owner the client (e.g. its computer operating system 272 or a highly privileged application). However, unlike the 273 HTTP Basic authentication scheme defined in [RFC2617], the 274 end-user's credentials are used in a single request and are 275 exchanged for an access token and refresh token which 276 eliminates the client need to store them for future use. 278 (C) The client requests an access token by authenticating with the 279 authorization server, and presenting the access grant. The 280 token request is described in Section 4. 282 (D) The authorization server validated the client credentials and 283 the access grant, and issues an access token with an optional 284 refresh token. Access token usually have a shorter lifetime 285 than the access grant. Refresh tokens usually have a lifetime 286 equal to the duration of the access grant. When an access token 287 expires, the refresh token is used to obtain a new access token 288 without having to request another access grant from the resource 289 owner (in which case, the refresh token acts as an access 290 grant). 292 (E) The client makes a protect resource request to the resource 293 server, and presents the access token in order to gain access. 294 Accessing a protected resource is described in Section 5. 296 (F) The resource server validates the access token, and if valid, 297 serves the request. 299 When the client is acting on behalf of itself (the client is also the 300 resource owner), the client skips steps (A) and (B), and does not 301 include an access grant in step (C). When the client uses the user- 302 agent profile (described in Section 1.4.2), the authorization request 303 (A) results in an access token (D), skipping steps (B) and (C). 305 The sizes of tokens and other values received from the authorization 306 server, are left undefined by this specification. Clients should 307 avoid making assumptions about value sizes. Servers should document 308 the expected size of any value they issue. 310 1.4. Client Profiles 312 OAuth supports a wide range of client types by providing a rich and 313 extensible framework for establishing authorization and exchaning it 314 for an access token. The methods detailed in this specification were 315 designed to accomodate four client types: web servers, user-agents, 316 native applications, and autonomous clients. Additional 317 authorization flows and client profiles may be defined by other 318 specifications to cover additional scenarios and client types. 320 1.4.1. Web Server 322 The web server profile is suitable for clients capable of interacting 323 with the end-user's user-agent (typically a web browser) and capable 324 of receiving incoming requests from the authorization server (capable 325 of acting as an HTTP server). 327 +----------+ Client Identifier +---------------+ 328 | -+----(A)--- & Redirect URI ------>| | 329 | End-user | | Authorization | 330 | at |<---(B)-- User authenticates --->| Server | 331 | Browser | | | 332 | -+----(C)-- Authorization Code ---<| | 333 +-|----|---+ +---------------+ 334 | | ^ v 335 (A) (C) | | 336 | | | | 337 ^ v | | 338 +---------+ | | 339 | |>---(D)-- Client Credentials, --------' | 340 | Web | Authorization Code, | 341 | Client | & Redirect URI | 342 | | | 343 | |<---(E)----- Access Token -------------------' 344 +---------+ (w/ Optional Refresh Token) 346 Figure 2: Web Server Flow 348 The web server flow illustrated in Figure 2 includes the following 349 steps: 351 (A) The web client initiates the flow by redirecting the end-user's 352 user-agent to the end-user authorization endpoint as described 353 in Section 3 using client type "web_server". The client 354 includes its client identifier, requested scope, local state, 355 and a redirect URI to which the authorization server will send 356 the end-user back once access is granted (or denied). 358 (B) The authorization server authenticates the end-user (via the 359 user-agent) and establishes whether the end-user grants or 360 denies the client's access request. 362 (C) Assuming the end-user granted access, the authorization server 363 redirects the user-agent back to the client to the redirection 364 URI provided earlier. The authorization includes an 365 authorization code for the client to use to obtain an access 366 token. 368 (D) The client requests an access token from the authorization 369 server by authenticating and including the authorization code 370 received in the previous step as described in Section 4. 372 (E) The authorization server validates the client credentials and 373 the authorization code and responds back with the access token. 375 1.4.2. User-Agent 377 The user-agent profile is suitable for client applications residing 378 in a user-agent, typically implemented in a browser using a scripting 379 language such as JavaScript. These clients cannot keep client 380 secrets confidential and the authentication of the client is based on 381 the user-agent's same-origin policy. 383 Unlike other profiles in which the client makes a separate end-user 384 authorization request and an access token requests, the client 385 receives the access token as a result of the end-user authorization 386 request in the form of an HTTP redirection. The client requests the 387 authorization server to redirect the user-agent to another web server 388 or local resource accessible to the user-agent which is capable of 389 extracting the access token from the response and passing it to the 390 client. 392 This user-agent profile does not utilize the client secret since the 393 client executables reside on the end-user's computer or device which 394 makes the client secret accessible and exploitable. Because the 395 access token is encoded into the redirection URI, it may be exposed 396 to the end-user and other applications residing on the computer or 397 device. 399 +----------+ Client Identifier +----------------+ 400 | |>---(A)-- & Redirection URI --->| | 401 | | | | 402 End <--+ - - - +----(B)-- User authenticates -->| Authorization | 403 User | | | Server | 404 | |<---(C)--- Redirect URI -------<| | 405 | Client | with Access Token | | 406 | in | (w/ Optional Authorization +----------------+ 407 | Browser | Code) in Fragment 408 | | +----------------+ 409 | |>---(D)--- Redirect URI ------->| | 410 | | without Fragment | Web Server | 411 | | | with Client | 412 | (F) |<---(E)--- Web Page with ------<| Resource | 413 | Access | Script | | 414 | Token | +----------------+ 415 +----------+ 417 Figure 3: User-Agent Flow 419 The user-agent flow illustrated in Figure 3 includes the following 420 steps: 422 (A) The client sends the user-agent to the end-user authorization 423 endpoint as described in Section 3 using client type 424 "user-agent". The client includes its client identifier, 425 requested scope, local state, and a redirect URI to which the 426 authorization server will send the end-user back once 427 authorization is granted (or denied). 429 (B) The authorization server authenticates the end-user (via the 430 user-agent) and establishes whether the end-user grants or 431 denies the client's access request. 433 (C) If the end-user granted access, the authorization server 434 redirects the user-agent to the redirection URI provided 435 earlier. The redirection URI includes the access token (and an 436 optional authorization code) in the URI fragment. 438 (D) The user-agent follows the redirection instructions by making a 439 request to the web server which does not include the fragment. 440 The user-agent retains the fragment information locally. 442 (E) The web server returns a web page (typically an HTML page with 443 an embedded script) capable of accessing the full redirection 444 URI including the fragment retained by the user-agent, and 445 extracting the access token (and other parameters) contained in 446 the fragment. 448 (F) The user-agent executes the script provided by the web server 449 which extracts the access token and passes it to the client. If 450 an authorization code was issued, the client can pass it to a 451 web server component to obtain another access token for 452 additional server-based protected resources interaction. 454 1.4.3. Native Application 456 Native application are clients running as native code on the end- 457 user's computer or device (i.e. executing outside a user-agent or as 458 a desktop program). These clients are often capable of interacting 459 with (or embedding) the end-user's user-agent but are incapable of 460 receiving callback requests from the server (incapable of acting as 461 an HTTP server). 463 Native application clients can be implemented in different ways based 464 on their requirements and desired end-user experience. Native 465 application clients can: 467 o Utilize the end-user authorization endpoint as described in 468 Section 3 by launching an external user-agent. The client can 469 capture the response by providing a redirection URI with a custom 470 URI scheme (registered with the operating system to invoke the 471 client application), or by providing a redirection URI pointing to 472 a server-hosted resource under the client's control which puts the 473 response in the user-agent window title (from which the client can 474 obtain the response by polling the user-agnet window, looking for 475 a window title change). 477 o Utilize the end-user authorization endpoint as described in 478 Section 3 by using an embedded user-agent. The client obtains the 479 response by directly communicating with the embedded user-agent. 481 o Prompt end-users for their basic credentials (username and 482 password) and use them directly to obtain an access token. This 483 is generally discouraged as it hands the end-user's password 484 directly to the 3rd party and is limited to basic credentials. 486 When choosing between launching an external browser and an embedded 487 user-agent, developers should consider the following: 489 o External user-agents may improve completion rate as the end-user 490 may already be logged-in and not have to re-authenticate. 492 o Embedded user-agents often offer a better end-user flow, as they 493 remove the need to switch context and open new windows. 495 o Embedded user-agents are less secure because users are 496 authenticating in unidentified window without access to the 497 protections offered by many user-agents. 499 1.4.4. Autonomous 501 Autonomous clients act on their own behalf (the client is also the 502 resource owner), or utilize existing trust relationship or framework 503 to establish authorization without directly involving the resource 504 owner. 506 Autonomous clients can be implemented in different ways based on 507 their requirements and the existing trust framework they rely upon. 508 Autonomous clients can: 510 o Obtain an access token by authenticating with the authorization 511 server using their client credentials. The scope of the access 512 token is limited to the protected resources under the control of 513 the client. 515 o Use an existing access grant expressed as an assertion using an 516 assertion format supported by the authorization server. Using 517 assertions requires the client to obtain a assertion (such as a 518 SAML [OASIS.saml-core-2.0-os] assertion) from an assertion issuer 519 or to self-issue an assertion. The assertion format, the process 520 by which the assertion is obtained, and the method of validating 521 the assertion are defined by the assertion issuer and the 522 authorization server, and are beyond the scope of this 523 specification. 525 2. Client Credentials 527 When interacting with the authorization server, the client identifies 528 itself using a set of client credentials. The client credentials 529 include a client identifier and MAY include a secret or other means 530 for the authorization server to authenticate the client. 532 The means through which the client obtains its credentials are beyond 533 the scope of this specification, but usually involve registration 534 with the authorization server. [[ OAuth Discovery provides one way of 535 obtaining basic client credentials ]] 537 Due to the nature of some clients, authorization servers SHOULD NOT 538 make assumptions about the confidentiality of client credentials 539 without establishing trust with the client operator. Authorization 540 servers SHOULD NOT issue client secrets to clients incapable of 541 keeping their secrets confidential. 543 This specification provides one mean of authenticating the client 544 using a set of basic client credentials. The authorization server 545 MAY authenticate the client using any desired authentication scheme. 547 2.1. Basic Client Credentials 549 The basic client credentials include a client identifier and an 550 OPTIONAL matching shared symmetric secret. The client identifier and 551 secret are included in the request using the HTTP Basic 552 authentication scheme as defined in [RFC2617] by including the client 553 identifier as the username and secret as the password. 555 For example (line breaks are for display purposes only): 557 POST /token HTTP/1.1 558 Host: server.example.com 559 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 560 Content-Type: application/x-www-form-urlencoded 562 type=web_server&code=i1WsRn1uB1& 563 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 565 Alternatively, the client MAY include the credentials using the 566 following request parameters: 568 client_id 569 REQUIRED. The client identifier. 571 client_secret REQUIRED if the client identifier has a matching 572 secret. 574 For example (line breaks are for display purposes only): 576 POST /token HTTP/1.1 577 Host: server.example.com 578 Content-Type: application/x-www-form-urlencoded 580 type=web_server&client_id=s6BhdRkqt3& 581 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 582 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 584 The client MAY include the client credentials using other HTTP 585 authentication schemes which support authenticating using a username 586 and password. The client MUST NOT include the client credentials 587 using more than one mechanism. If more than one mechanism is used, 588 regardless whether the credentials are identical or valid, the server 589 MUST reply with an HTTP 400 status code (Bad Request) and include the 590 "multiple_credentials" error code. 592 The authorization server MUST accept the client credentials using 593 both the request parameters, and the HTTP Basic authentication 594 scheme. The authorization server MAY support additional 595 authentication schemes. 597 3. Obtaining End-User Authorization 599 When the client interacts with an end-user, the end-user MUST first 600 grant the client authorization to access its protected resources. 601 Once obtained, the end-user access grant is expressed as an 602 authorization code which the client uses to obtain an access token. 603 To obtain an end-user authorization, the client sends the end-user to 604 the end-user authorization endpoint. 606 At the end-user authorization endpoint, the end-user first 607 authenticates with the authorization server, and then grants or 608 denies the access request. The way in which the authorization server 609 authenticates the end-user (e.g. username and password login, OpenID, 610 session cookies) and in which the authorization server obtains the 611 end-user's authorization, including whether it uses a secure channel 612 such as TLS, is beyond the scope of this specification. However, the 613 authorization server MUST first verify the identity of the end-user. 615 The location of the end-user authorization endpoint can be found in 616 the service documentation, or can be obtained by using [[ OAuth 617 Discovery ]]. The end-user authorization endpoint URI MAY include a 618 query component as defined by [RFC3986] section 3, which must be 619 retained when adding additional query parameters. 621 Since requests to the end-user authorization endpoint result in user 622 authentication and the transmission of sensitive information, the 623 authorization server SHOULD require the use of a transport-layer 624 mechanism such as TLS when sending requests to the end-user 625 authorization endpoint. 627 In order to direct the end-user's user-agent to the authorization 628 server, the client constructs the request URI by adding the following 629 parameters to the end-user authorization endpoint URI query component 630 using the "application/x-www-form-urlencoded" format as defined by 631 [W3C.REC-html401-19991224]: 633 type 634 REQUIRED. The client type (user-agent or web server). 635 Determines how the authorization server delivers the 636 authorization response back to the client. The parameter value 637 MUST be set to "web_server" or "user_agent". 639 client_id 640 REQUIRED. The client identifier as described in Section 2. 642 redirect_uri 643 REQUIRED, unless a redirection URI has been established between 644 the client and authorization server via other means. An 645 absolute URI to which the authorization server will redirect 646 the user-agent to when the end-user authorization step is 647 completed. The authorization server SHOULD require the client 648 to pre-register their redirection URI. Authorization servers 649 MAY restrict the redirection URI to not include a query 650 component as defined by [RFC3986] section 3. 652 state 653 OPTIONAL. An opaque value used by the client to maintain state 654 between the request and callback. The authorization server 655 includes this value when redirecting the user-agent back to the 656 client. 658 scope 659 OPTIONAL. The scope of the access request expressed as a list 660 of space-delimited strings. The value of the "scope" parameter 661 is defined by the authorization server. If the value contains 662 multiple space-delimited strings, their order does not matter, 663 and each string adds an additional access range to the 664 requested scope. 666 The client directs the end-user to the constructed URI using an HTTP 667 redirection response, or by other means available to it via the end- 668 user's user-agent. The request MUST use the HTTP "GET" method. 670 For example, the client directs the end-user's user-agent to make the 671 following HTTPS request (line breaks are for display purposes only): 673 GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri= 674 https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 675 Host: server.example.com 677 If the client has previously registered a redirection URI with the 678 authorization server, the authorization server MUST verify that the 679 redirection URI received matches the registered URI associated with 680 the client identifier. [[ provide guidance on how to perform matching 681 ]] 683 The authorization server authenticates the end-user and obtains an 684 authorization decision (by asking the end-user or by establishing 685 approval via other means). When a decision has been established, the 686 authorization server directs the end-user's user-agent to the 687 provided client redirection URI using an HTTP redirection response, 688 or by other means available to it via the end-user's user-agent. 690 3.1. Authorization Server Response 692 If the end-user grants the access request, the authorization server 693 issues an access token, an authorization code, or both, and delivers 694 them to the client by adding the following parameters to the 695 redirection URI: 697 code 698 REQUIRED if the client type is "web_server", otherwise 699 OPTIONAL. The authorization code generated by the 700 authorization server. The authorization code SHOULD expire 701 shortly after it is issued and allowed for a single use. The 702 authorization code is bound to the client identifier and 703 redirection URI. 705 access_token 706 REQUIRED if the client type is "user_agent", otherwise MUST NOT 707 be included. The access token. 709 expires_in 710 OPTIONAL. The duration in seconds of the access token lifetime 711 if an access token is included. 713 state 714 REQUIRED if the "state" parameter was present in the client 715 authorization request. Set to the exact value received from 716 the client. 718 If the end-user denies the access request, the authorization server 719 informs the client by adding the following parameters to the 720 redirection URI: 722 error 723 REQUIRED. The parameter value MUST be set to "user_denied". 725 state 726 REQUIRED if the "state" parameter was present in the client 727 authorization request. Set to the exact value received from 728 the client. 730 The method in which the authorization server adds the parameter to 731 the redirection URI is determined by the client type provided by the 732 client in the authorization request using the "type" parameter. 734 If the client type is "web_server", the authorization server adds the 735 parameters to the redirection URI query component using the 736 "application/x-www-form-urlencoded" format as defined by 737 [W3C.REC-html401-19991224]. 739 For example, the authorization server redirects the end-user's user- 740 agent by sending the following HTTP response: 742 HTTP/1.1 302 Found 743 Location: https://client.example.com/cb?code=i1WsRn1uB1 745 If the client type is "user_agent", the authorization server adds the 746 parameters to the redirection URI fragment component using the 747 "application/x-www-form-urlencoded" format as defined by 748 [W3C.REC-html401-19991224]. [[ replace form-encoded with JSON? ]] 750 For example, the authorization server redirects the end-user's user- 751 agent by sending the following HTTP response: 753 HTTP/1.1 302 Found 754 Location: http://example.com/rd#access_token=FJQbwq9&expires_in=3600 756 4. Obtaining an Access Token 758 The client obtains an access token by authenticating with the 759 authorization server and presenting its access grant. 761 After obtaining authorization from the resource owner, clients 762 request an access token from the authorization server's token 763 endpoint. When requesting an access token, the client authenticates 764 with the authorization server and includes the access grant (in the 765 form of an authorization code, resource owner credentials, an 766 assertion, or a refresh token). 768 The location of the token endpoint can be found in the service 769 documentation, or can be obtained by using [[ OAuth Discovery ]]. 770 The token endpoint URI MAY include a query component, which must be 771 retained when adding additional query parameters. 773 Since requests to the token endpoint result in the transmission of 774 plain text credentials in the HTTP request and response, the 775 authorization server MUST require the use of a transport-layer 776 mechanism when sending requests to the token endpoints. Servers MUST 777 support TLS 1.2 as defined in [RFC5246] and MAY support addition 778 mechanisms with equivalent protections. 780 The client requests an access token by constructing a token request 781 and making an HTTP "POST" request. The client constructs the request 782 URI by adding its client credentials to the request as described in 783 Section 2, and includes the following parameters using the 784 "application/x-www-form-urlencoded" format in the HTTP request 785 entity-body: 787 grant_type 788 REQUIRED. The access grand type included in the request. 789 Value MUST be one of "authorization_code", 790 "user_basic_credentials", "assertion", "refresh_token", or 791 "none" (which indicates the client is acting on behalf of 792 itself). 794 scope 795 OPTIONAL. The scope of the access request expressed as a list 796 of space-delimited strings. The value of the "scope" parameter 797 is defined by the authorization server. If the value contains 798 multiple space-delimited strings, their order does not matter, 799 and each string adds an additional access range to the 800 requested scope. If the access grant being used already 801 represents an approved scope (e.g. authorization code, 802 assertion), the requested scope MUST be equal or lesser than 803 the scope previously granted. 805 In addition, the client MUST include the appropriate parameters 806 listed for the selected access grant type as described in 807 Section 4.1. 809 4.1. Access Grant Parameters 811 4.1.1. Authorization Code 813 The client includes the authorization code using the 814 "authorization_code" access grant type and the following parameters: 816 code 817 REQUIRED. The authorization code received from the 818 authorization server. 820 redirect_uri 821 REQUIRED. The redirection URI used in the initial request. 823 For example, the client makes the following HTTPS request (line 824 breaks are for display purposes only): 826 POST /token HTTP/1.1 827 Host: server.example.com 828 Content-Type: application/x-www-form-urlencoded 830 grant_type=authorization_code&client_id=s6BhdRkqt3& 831 client_secret=gX1fBat3bV&code=i1WsRn1uB1& 832 redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 834 The authorization server MUST verify that the authorization code, 835 client identity, client secret, and redirection URI are all valid and 836 match its stored association. If the request is valid, the 837 authorization server issues a successful response as described in 838 Section 4.2. 840 4.1.2. Resource Owner Basic Credentials 842 The client includes the resource owner credentials using the 843 following parameters: [[ add internationalization consideration for 844 username and password ]] 846 username 847 REQUIRED. The end-user's username. 849 password 850 REQUIRED. The end-user's password. 852 For example, the client makes the following HTTPS request (line 853 breaks are for display purposes only): 855 POST /token HTTP/1.1 856 Host: server.example.com 857 Content-Type: application/x-www-form-urlencoded 859 grant_type=user_basic&client_id=s6BhdRkqt3& 860 client_secret=47HDu8s&username=johndoe&password=A3ddj3w 862 The authorization server MUST validate the client credentials and 863 end-user credentials and if valid issues an access token response as 864 described in Section 4.2. 866 4.1.3. Assertion 868 The client includes the assertion using the following parameters: 870 assertion_type 871 REQUIRED. The format of the assertion as defined by the 872 authorization server. The value MUST be an absolute URI. 874 assertion 875 REQUIRED. The assertion. 877 For example, the client makes the following HTTPS request (line 878 breaks are for display purposes only): 880 POST /token HTTP/1.1 881 Host: server.example.com 882 Content-Type: application/x-www-form-urlencoded 884 grant_type=assertion&client_id=s6BhdRkqt3&client_secret=diejdsks& 885 assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 886 assertion=PHNhbWxwOl...[ommited for brevity]...ZT4%3D 888 The authorization server MUST validate the assertion and if valid 889 issues an access token response as described in Section 4.2. The 890 authorization server SHOULD NOT issue a refresh token. 892 Authorization servers SHOULD issue access tokens with a limited 893 lifetime and require clients to refresh them by requesting a new 894 access token using the same assertion if it is still valid. 895 Otherwise the client MUST obtain a new valid assertion. 897 4.1.4. Refresh Token 899 The client includes the refresh token using the following parameters: 901 refresh_token 902 REQUIRED. The refresh token associated with the access token 903 to be refreshed. 905 For example, the client makes the following HTTPS request (line break 906 are for display purposes only): 908 POST /token HTTP/1.1 909 Host: server.example.com 910 Content-Type: application/x-www-form-urlencoded 912 grant_type=refresh_token&client_id=s6BhdRkqt3& 913 client_secret=8eSEIpnqmM&refresh_token=n4E9O119d 915 The authorization server MUST verify the client credentials, the 916 validity of the refresh token, and that the resource owner's 917 authorization is still valid. If the request is valid, the 918 authorization server issues an access token response as described in 919 Section 4.2. The authorization server MAY issue a new refresh token 920 in which case the client MUST NOT use the previous refresh token and 921 replace it with the newly issued refresh token. 923 4.2. Access Token Response 925 After receiving and verifying a valid and authorized access token 926 request from the client, the authorization server issues the access 927 token and optional refresh token, and constructs the response by 928 adding the following parameters to the entity body of the HTTP 929 response with a 200 status code (OK): 931 The token response contains the following parameters: 933 access_token 934 REQUIRED. The access token issued by the authorization server. 936 expires_in 937 OPTIONAL. The duration in seconds of the access token 938 lifetime. 940 refresh_token 941 OPTIONAL. The refresh token used to obtain new access tokens 942 using the same end-user access grant as described in 943 Section 4.1.4. 945 scope 946 OPTIONAL. The scope of the access token as a list of space- 947 delimited strings. The value of the "scope" parameter is 948 defined by the authorization server. If the value contains 949 multiple space-delimited strings, their order does not matter, 950 and each string adds an additional access range to the 951 requested scope. 953 The parameters are including in the entity body of the HTTP response 954 using the "application/json" media type as defined by [RFC4627]. The 955 parameters are serialized into a JSON structure by adding each 956 parameter at the highest structure level. Parameter names and string 957 values are included as JSON strings. Numerical values are included 958 as JSON numbers. 960 The authorization server MUST include the HTTP "Cache-Control" 961 response header field with a value of "no-store" in any response 962 containing tokens, secrets, or other sensitive information. 964 For example: 966 HTTP/1.1 200 OK 967 Content-Type: application/json 968 Cache-Control: no-store 970 { 971 "access_token":"SlAV32hkKG", 972 "expires_in":3600, 973 "refresh_token":"8xLOxBtZp8" 974 } 976 4.3. Error Response 978 If the token request is invalid or unauthorized, the authorization 979 server constructs the response by adding the following parameter to 980 the entity body of the HTTP response with a a 400 status code (Bad 981 Request) using the "application/json" media type: 983 error 984 REQUIRED. The error code as described in Section 4.3.1. 986 For example: 988 HTTP/1.1 400 Bad Request 989 Content-Type: application/json 990 Cache-Control: no-store 992 { 993 "error":"incorrect_client_credentials" 994 } 996 4.3.1. Error Codes 998 [[ expalain each error code: ]] 1000 o "redirect_uri_mismatch" 1002 o "bad_authorization_code" 1004 o "invalid_client_credentials" 1006 o "unauthorized_client'" - The client is not permitted to use this 1007 access grant type. 1009 o "invalid_assertion" 1011 o "unknown_format" 1013 o "authorization_expired" 1015 o "multiple_credentials" 1017 o "invalid_user_credentials" 1019 5. Accessing a Protected Resource 1021 Clients access protected resources by presenting an access token to 1022 the resource server. 1024 For example: 1026 GET /resource HTTP/1.1 1027 Host: server.example.com 1028 Authorization: Token token="vF9dft4qmT" 1030 Access tokens act as bearer tokens, where the token string acts as a 1031 shared symmetric secret. This requires treating the access token 1032 with the same care as other secrets (e.g. end-user passwords). 1033 Access tokens SHOULD NOT be sent in the clear over an insecure 1034 channel. 1036 However, when it is necessary to transmit bearer tokens in the clear 1037 without a secure channel, authorization servers SHOULD issue access 1038 tokens with limited scope and lifetime to reduce the potential risk 1039 from a compromised access token. 1041 Clients SHOULD NOT make authenticated requests with an access token 1042 to unfamiliar resource servers, especially when using bearer tokens, 1043 regardless of the presence of a secure channel. 1045 The methods used by the resource server to validate the access token 1046 are beyond the scope of this specification, but generally involve an 1047 interaction or coordination between the resource server and 1048 authorization server. 1050 The resource server MUST validate the access token and ensure it has 1051 not expired and that its scope covers the requested resource. If the 1052 token expired or is invalid, the resource server MUST reply with an 1053 HTTP 401 status code (Unauthorized) and include the HTTP 1054 "WWW-Authenticate" response header field as described in Section 6. 1056 For example: 1058 HTTP/1.1 401 Unauthorized 1059 WWW-Authenticate: Token realm='Service', error='token_expired' 1061 Clients make authenticated token requests using the "Authorization" 1062 request header field as described in Section 5.1. Alternatively, 1063 clients MAY include the access token using the HTTP request URI in 1064 the query component as described in Section 5.2, or in the HTTP body 1065 when using the "application/x-www-form-urlencoded" content type as 1066 described in Section 5.3. 1068 Clients SHOULD only use the request URI or body when the 1069 "Authorization" request header field is not available, and MUST NOT 1070 use more than one method in each request. [[ specify error ]] 1072 5.1. The Authorization Request Header Field 1074 The "Authorization" request header field is used by clients to make 1075 authenticated token requests. The client uses the "token" attribute 1076 to include the access token in the request. 1078 The "Authorization" header field uses the framework defined by 1079 [RFC2617] as follows: 1081 credentials = "Token" RWS access-token [ CS 1#auth-param ] 1082 access-token = "token" "=" <"> token <"> 1083 CS = OWS "," OWS 1085 5.2. URI Query Parameter 1087 When including the access token in the HTTP request URI, the client 1088 adds the access token to the request URI query component as defined 1089 by [RFC3986] using the "oauth_token" parameter. 1091 For example, the client makes the following HTTPS request: 1093 GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 1094 Host: server.example.com 1096 The HTTP request URI query can include other request-specific 1097 parameters, in which case, the "oauth_token" parameters SHOULD be 1098 appended following the request-specific parameters, properly 1099 separated by an "&" character (ASCII code 38). 1101 The resource server MUST validate the access token and ensure it has 1102 not expired and its scope includes the requested resource. If the 1103 resource expired or is not valid, the resource server MUST reply with 1104 an HTTP 401 status code (Unauthorized) and include the HTTP 1105 "WWW-Authenticate" response header field as described in Section 6. 1107 5.3. Form-Encoded Body Parameter 1109 When including the access token in the HTTP request entity-body, the 1110 client adds the access token to the request body using the 1111 "oauth_token" parameter. The client can use this method only if the 1112 following REQUIRED conditions are met: 1114 o The entity-body is single-part. 1116 o The entity-body follows the encoding requirements of the 1117 "application/x-www-form-urlencoded" content-type as defined by 1118 [W3C.REC-html401-19991224]. 1120 o The HTTP request entity-header includes the "Content-Type" header 1121 field set to "application/x-www-form-urlencoded". 1123 o The HTTP request method is "POST", "PUT", or "DELETE". 1125 The entity-body can include other request-specific parameters, in 1126 which case, the "oauth_token" parameters SHOULD be appended following 1127 the request-specific parameters, properly separated by an "&" 1128 character (ASCII code 38). 1130 For example, the client makes the following HTTPS request: 1132 POST /resource HTTP/1.1 1133 Host: server.example.com 1134 Content-Type: application/x-www-form-urlencoded 1136 oauth_token=vF9dft4qmT 1138 The resource server MUST validate the access token and ensure it has 1139 not expired and its scope includes the requested resource. If the 1140 resource expired or is not valid, the resource server MUST reply with 1141 an HTTP 401 status code (Unauthorized) and include the HTTP 1142 "WWW-Authenticate" response header field as described in Section 6. 1144 6. The WWW-Authenticate Response Header Field 1146 Clients access protected resources after locating the appropriate 1147 end-user authorization endpoint and token endpoint and obtaining an 1148 access token. In many cases, interacting with a protected resource 1149 requires prior knowledge of the protected resource properties and 1150 methods, as well as its authentication requirements (i.e. 1151 establishing client identity, locating the end-user authorization and 1152 token endpoints). 1154 However, there are cases in which clients are unfamiliar with the 1155 protected resource, including whether the resource requires 1156 authentication. When clients attempt to access an unfamiliar 1157 protected resource without an access token, the resource server 1158 denies the request and informs the client of the required credentials 1159 using an HTTP authentication challenge. 1161 In addition, when receiving an invalid authenticated request, the 1162 resource server issues an authentication challenge including the 1163 error type and message. 1165 A resource server receiving a request for a protected resource 1166 without a valid access token MUST respond with a 401 (Unauthorized) 1167 or 403 (Forbidden) HTTP status code, and include at least one "Token" 1168 "WWW-Authenticate" response header field challenge. 1170 The "WWW-Authenticate" header field uses the framework defined by 1171 [RFC2617] as follows: 1173 challenge = "Token" RWS token-challenge 1175 token-challenge = realm 1176 [ CS error ] 1177 [ CS 1#auth-param ] 1179 error = "error" "=" <"> token <"> 1181 The "realm" attribute is used to provide the protected resources 1182 partition as defined by [RFC2617]. 1184 The "error" attribute is used to inform the client the reason why an 1185 access request was declined. [[ Add list of error codes ]] 1187 7. Security Considerations 1189 [[ todo ]] 1191 8. IANA Considerations 1193 [[ Not Yet ]] 1195 Appendix A. Examples 1197 [[ todo ]] 1199 Appendix B. Contributors 1201 The following people contributed to preliminary versions of this 1202 document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland 1203 (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), 1204 Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and 1205 concepts within are a product of the OAuth community, WRAP community, 1206 and the OAuth Working Group. 1208 The OAuth Working Group has dozens of very active contributors who 1209 proposed ideas and wording for this document, including: [[ If your 1210 name is missing or you think someone should be added here, please 1211 send Eran a note - don't be shy ]] 1213 Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah 1214 Culver, Igor Faynberg, George Fletcher, Evan Gilbert, Justin Hart, 1215 John Kemp, Torsten Lodderstedt, Eve Maler, James Manger, Chuck 1216 Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, 1217 Marius Scurtescu, Justin Smith, and Franklin Tse. 1219 Appendix C. Acknowledgements 1221 [[ Add OAuth 1.0a authors + WG contributors ]] 1223 Appendix D. Document History 1225 [[ to be removed by RFC editor before publication as an RFC ]] 1227 -08 1229 o Renamed verification code to authorization code. 1231 o Revised terminology, structured section, added new terms. 1233 o Changed flows to profiles and moved to introduction. 1235 o Added support for access token rescoping. 1237 o Cleaned up client credentials section. 1239 o New introduction overview. 1241 o Added error code for invalid username and password, and renamed 1242 error code to be more consistent. 1244 o Added access grant type parameter to token endpoint. 1246 -07 1248 o Major rewrite of entire document structure. 1250 o Removed device profile. 1252 o Added verification code support to user-agent flow. 1254 o Removed multiple formats support, leaving JSON as the only format. 1256 o Changed assertion "assertion_format" parameter to 1257 "assertion_type". 1259 o Removed "type" parameter from token endpoint. 1261 -06 1262 o Editorial changes, corrections, clarifications, etc. 1264 o Removed conformance section. 1266 o Moved authors section to contributors appendix. 1268 o Added section on native applications. 1270 o Changed error response to use the requested format. Added support 1271 for HTTP "Accept" header. 1273 o Flipped the order of the web server and user-agent flows. 1275 o Renamed assertion flow "format" parameter name to 1276 "assertion_format" to resolve conflict. 1278 o Removed the term identifier from token definitions. Added a 1279 cryptographic token definition. 1281 o Added figure titles. 1283 o Added server response 401 when client tried to authenticate using 1284 multiple credentials. 1286 o Clarified support for TLS alternatives, and added requirement for 1287 TLS 1.2 support for token endpoint. 1289 o Removed all signature and cryptography. 1291 o Removed all discovery. 1293 o Updated HTML4 reference. 1295 -05 1297 o Corrected device example. 1299 o Added client credentials parameters to the assertion flow as 1300 OPTIONAL. 1302 o Added the ability to send client credentials using an HTTP 1303 authentication scheme. 1305 o Initial text for the "WWW-Authenticate" header (also added scope 1306 support). 1308 o Change authorization endpoint to end-user endpoint. 1310 o In the device flow, change the "user_uri" parameter to 1311 "verification_uri" to avoid confusion with the end-user endpoint. 1313 o Add "format" request parameter and support for XML and form- 1314 encoded responses. 1316 -04 1318 o Changed all token endpoints to use "POST" 1320 o Clarified the authorization server's ability to issue a new 1321 refresh token when refreshing a token. 1323 o Changed the flow categories to clarify the autonomous group. 1325 o Changed client credentials language not to always be server- 1326 issued. 1328 o Added a "scope" response parameter. 1330 o Fixed typos. 1332 o Fixed broken document structure. 1334 -03 1336 o Fixed typo in JSON error examples. 1338 o Fixed general typos. 1340 o Moved all flows sections up one level. 1342 -02 1344 o Removed restriction on "redirect_uri" including a query. 1346 o Added "scope" parameter. 1348 o Initial proposal for a JSON-based token response format. 1350 -01 1352 o Editorial changes based on feedback from Brian Eaton, Bill Keenan, 1353 and Chuck Mortimore. 1355 o Changed device flow "type" parameter values and switch to use only 1356 the token endpoint. 1358 -00 1360 o Initial draft based on a combination of WRAP and OAuth 1.0a. 1362 9. References 1364 9.1. Normative References 1366 [I-D.ietf-httpbis-p1-messaging] 1367 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1368 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 1369 "HTTP/1.1, part 1: URIs, Connections, and Message 1370 Parsing", draft-ietf-httpbis-p1-messaging-09 (work in 1371 progress), March 2010. 1373 [NIST FIPS-180-3] 1374 National Institute of Standards and Technology, "Secure 1375 Hash Standard (SHS). FIPS PUB 180-3, October 2008". 1377 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1378 Extensions (MIME) Part One: Format of Internet Message 1379 Bodies", RFC 2045, November 1996. 1381 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1382 Hashing for Message Authentication", RFC 2104, 1383 February 1997. 1385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1386 Requirement Levels", BCP 14, RFC 2119, March 1997. 1388 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1389 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1390 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1392 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1393 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1394 Authentication: Basic and Digest Access Authentication", 1395 RFC 2617, June 1999. 1397 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1399 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1400 Types", RFC 3023, January 2001. 1402 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1403 Standards (PKCS) #1: RSA Cryptography Specifications 1404 Version 2.1", RFC 3447, February 2003. 1406 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1407 10646", STD 63, RFC 3629, November 2003. 1409 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1410 Resource Identifier (URI): Generic Syntax", STD 66, 1411 RFC 3986, January 2005. 1413 [RFC4627] Crockford, D., "The application/json Media Type for 1414 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1416 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1417 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1419 [W3C.REC-html401-19991224] 1420 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1421 Specification", World Wide Web Consortium 1422 Recommendation REC-html401-19991224, December 1999, 1423 . 1425 9.2. Informative References 1427 [I-D.hammer-oauth] 1428 Hammer-Lahav, E., "The OAuth 1.0 Protocol", 1429 draft-hammer-oauth-10 (work in progress), February 2010. 1431 [I-D.hardt-oauth] 1432 Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web 1433 Resource Authorization Profiles", draft-hardt-oauth-01 1434 (work in progress), January 2010. 1436 [OASIS.saml-core-2.0-os] 1437 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1438 "Assertions and Protocol for the OASIS Security Assertion 1439 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1440 2.0-os, March 2005. 1442 Authors' Addresses 1444 Eran Hammer-Lahav (editor) 1445 Yahoo! 1447 Email: eran@hueniverse.com 1448 URI: http://hueniverse.com 1449 David Recordon 1450 Facebook 1452 Email: davidrecordon@facebook.com 1453 URI: http://www.davidrecordon.com/ 1455 Dick Hardt 1456 Microsoft 1458 Email: dick.hardt@gmail.com 1459 URI: http://dickhardt.org/