idnits 2.17.1 draft-barnes-oauth-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (July 8, 2009) is 5399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-hammer-oauth-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth R. Barnes 3 Internet-Draft M. Lepinski 4 Intended status: Informational BBN Technologies 5 Expires: January 9, 2010 July 8, 2009 7 The OAuth Security Model for Delegated Authorization 8 draft-barnes-oauth-model-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 9, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes the security model for the OAuth 47 authorization system, which allows a party that holds some 48 authorization to delegate a subset of that authorization to another 49 party, without requiring either party to disclose its credentials to 50 the other. In this document, we describe a set of design 51 constraints, a high-level work flow for establishing authorizations 52 subject to those constraints, and set of security requirements for 53 protocols that implement this model. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Requirements and design goals . . . . . . . . . . . . . . . . 5 60 3.1. Trust assumptions . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Threat model . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Authorization flow . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. General Requirements and Assumptions . . . . . . . . . . . 8 64 4.2. Request token issuance . . . . . . . . . . . . . . . . . . 9 65 4.3. Authorization of the request . . . . . . . . . . . . . . . 10 66 4.3.1. Request for authorization . . . . . . . . . . . . . . 10 67 4.3.2. Verification token issuance . . . . . . . . . . . . . 11 68 4.3.3. Notification of authorization . . . . . . . . . . . . 12 69 4.4. Access token issuance . . . . . . . . . . . . . . . . . . 13 70 4.5. Accessing protected resources . . . . . . . . . . . . . . 14 71 4.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5. Security analysis . . . . . . . . . . . . . . . . . . . . . . 17 73 5.1. Protection from outside interference . . . . . . . . . . . 17 74 5.2. Protection from malicious actors within the model . . . . 18 75 5.3. Protection from colluding actors . . . . . . . . . . . . . 19 76 5.4. Protection from denial of service . . . . . . . . . . . . 20 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 9. Normative References . . . . . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 It is an almost universal situation in the Internet today that users 86 make use of many Internet applications, some of which store data for 87 the user and some of which consume user data. There is increasing 88 interest in bringing these two types of application together, i.e., 89 in allowing certain applications that consume user data to access 90 data that is stored by other applications. 92 However, in order to maintain the security of user data, applications 93 that store data typically require an entity requesting private 94 resources to authenticate that they own those resources (i.e., to 95 authenticate as the owner of the resources). Enabling a second 96 application to access private resources would thus require the user 97 who ones the resources to enable that application to authenticate as 98 the user. This situation is clearly undesirable, since it allows the 99 consuming application to impersonate the user: To access any and all 100 data the user owns, or to take actions as the user. 102 This situation has created a need for a mechanism for delegating 103 authorization. In such a system, the owner of a set of resources can 104 delegate access to some of those resources to a designated client 105 application, without enabling the client application to impersonate 106 the user. 108 There are two basic prerequisites of such a delegation mechanism: 109 First, applications that store user data must have separate notions 110 of ownership and access permissions; this, of course, is not subject 111 to standardization. Second, there must be a way for client 112 applications to request access, and for users to instruct servers to 113 grant such access. This second aspect is the subject of this 114 document. 116 This document describes a security model for the OAuth delegated 117 authorization system. In particular, we provide an abstract message 118 flow that defines how parameters are exchanged between OAuth 119 entities, and what the security requirements are for these exchanges. 120 The definition of protocol mechanisms for conveying parameters in 121 compliance with these requirements is left to future documents. 123 [[ Editor's note: This document is essentially an abstraction and 124 security analysis of the OAuth Core protocol, defined in [1]. While 125 the current OAuth protocol should map more or less directly to this 126 model, there may be slight difference, e.g., in where authentication 127 is required. ]] 129 2. Definitions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [2]. 135 The focus of this document is the secure delegation of access to 136 resources. In this document, we use the term "resources" broadly, to 137 include actual data (e.g., files, streams) as well as permissions to 138 take particular actions. 140 There are three roles involved in the OAuth process. These roles are 141 not mutually exclusive; a single party may act in more than one role. 143 Resource Owner (RO): The entity that has authorization at the 144 beginning of the OAuth process, who delegates authorization to the 145 Client 147 Client: The entity to which authorization is delegated by the 148 Resource Owner 150 Server: The entity that enforces the authorizations in question 151 (e.g., the server that stores a protected resource) 153 [[ Editor's note: These three roles correspond to the User, the 154 Consumer, and the Service Provider in OAuth 1.0, available at 155 http://oauth.net/ ]] 157 An OAuth Server issues three types of opaque tokens in the course of 158 the authorization process. These values are random values that are 159 unique within a defined scope. 161 Request token: A temporary identifier for a specific Client for the 162 duration of a single OAuth authorization transaction. An RO that 163 requests a verification token using that request token indicates 164 that the corresponding Client is the entity to be authorized. 166 Verification token: A temporary identifier for an authorization, 167 including the authorized Client, the authorizing RO, and the 168 resources to which access is to be granted. A Client that 169 requests an access token using a given verification token 170 indicates that the RO has granted the corresponding authorization. 172 Access token: A long-lived identifier for an authorization. A 173 Client that requests access to resources using a given access 174 token indicates that it has been authorized via the OAuth process 175 to access those resources. 177 Many of the security properties of the OAuth process require protocol 178 participants to associate, or "bind", certain other data to tokens, 179 then subsequently verify these associations/bindings. In the below, 180 when an entity is required to use the value "bound to a token" or 181 "associated with a token", it is implied that the value in question 182 is the one associated by the entity at hand. 184 3. Requirements and design goals 186 The fundamental goal of the OAuth model is to allow the Resource 187 Owner to grant the Client authorization to access selected resources 188 on the Server, while maintaining strict authentication and access 189 control. The requirement for strict authentication means that no 190 party should be able to authenticate as any other, whether a protocol 191 participant (e.g., the Client authenticating as the RO) or a third 192 party. The requirement for access control means that the delegation 193 process should not grant the Client (or any other party) access to 194 anything other than the resources designated for access by the 195 Resource Owner. 197 The OAuth model must also ensure that the authorization process is 198 followed: In order for an authorization to be delegated by a Resource 199 Owner to a Client, it must be requested by the Client and authorized 200 by the Resource Owner. In particular, the RO cannot unilaterally 201 grant authorization to a Client without a request (since the Client 202 may not be able to use that authorization), and of course, no 203 authorization can be granted without the approval of the RO. In 204 addition, the security model should prevent the Client from further 205 delegating access without going through the same OAuth process. 207 It should be clear that these requirements already rule out the 208 simplest models for delegating authorization. For example, a model 209 in which the RO simply provides its authentication credentials to the 210 Client is unacceptable for several reasons: It allows the Client to 211 access all resources (not only any selected subset), and it requires 212 the Client to authenticate as the RO. 214 Note also that this document defines only the security model for 215 OAuth, i.e., how security-relevant data flow through the system, and 216 what the security requirements are for these flows. In particular, 217 this document does not define protocol mechanisms for carrying data 218 (e.g., tokens) or providing security features (e.g., authentication, 219 confidentiality). Such mechanisms should be defined in protocol- 220 specific documents (e.g., a realization of OAuth in HTTP or XMPP). 222 3.1. Trust assumptions 224 In the OAuth architecture, the Server is a trusted entity, in the 225 sense of RFC 4949 [3]: Since the Server is clearly capable of 226 providing anyone access to the protected resources, no further 227 analysis of the risks it presents is necessary; we assume it behaves 228 as specified. 230 The Resource Owner for a set of protected resources is also trusted 231 in the sense that it can authorize any request from a Client; we 232 assume that genuine ROs will only tell the server to authorize 233 requests from Clients that it genuinely intends to authorize. We do 234 not assume that any entity acting as an RO is the genuine RO for the 235 protected resources. It will be necessary for the OAuth system to 236 provide the Client and Server assurance that the RO in the process is 237 the genuine owner of the resources in question. (The Server can 238 verify this directly, with standard authentication mechanisms; the 239 Client will rely on an authenticated assertion by the Server.) 241 All parties are assumed to maintain the security of their private 242 authentication keys (the long-lived credentials that enable to 243 authenticate to other protocol entities). Beyond that minimal 244 assumption, we make no security assumptions about the behavior of the 245 Client. 247 3.2. Threat model 249 The authorization system here is designed to protect against four 250 classes of threats: 252 1. Outside intervention in an otherwise honest transaction 254 2. Malicious actors within the authorization process 256 3. Collusion among actors within the authorization process 258 4. Denial of service against the authorization process 260 The basic goal of the authorization system is to allow an honest 261 Client, Server, and RO to delegate authorization even in the presence 262 of external bad actors. This goal is mainly accomplished by 263 requiring authentication at critical points of the protocol to assure 264 that the parties are always talking among themselves, and not to some 265 outside actor. 267 OAuth is also intended to prevent the abuse of the authorization 268 process by legitimate participants in it, especially Clients. This 269 goal is addressed by a set of mechanisms that allow the Server and 270 the Resource Owner to validate that the authorization process is 271 conducted faithfully. 273 A more advanced class of attack is when two or more participants 274 collude in order to gain false access. The primary example of this 275 sort of attack is when two Clients collude so that the one more 276 trusted by the RO can obtain access on behalf of the other. This 277 class of attack is addressed by assuring that the Client is 278 consistently identified throughout the OAuth process. 280 Finally, there are several points in the OAuth process where the 281 injection of false information would cause the process to fail, even 282 in the absence of other problems. This threat can be minimized by 283 ensuring that only authentic protocol participants can contribute 284 information to the process. 286 4. Authorization flow 288 The OAuth authorization process is the process by which a Resource 289 Owner can grant a Client permission to access resources protected by 290 a Server. This process occurs in four high-level steps, illustrated 291 in Figure 1: 293 1. The Client obtains a Request Token from the Server 295 2. The Client requests authorization from the Resource Owner 297 3. The Resource Owner validates the request and grants authorization 299 4. The Client exchanges the Request Token for an Access Token 301 If the process fails at any point, no authorization is granted. 303 Client Server Resource Owner 304 | | | 305 | Issue Req. Token | | 306 |<---------------------->| | 307 | | | 308 | | Request authorization | 309 |------------------------------------------------>| 310 | | | 311 | | Issue Ver. Token | 312 | |<---------------------->| 313 | | | 314 | Grant authorization | | 315 |<------------------------------------------------| 316 | | | 317 | Issue Acc. Token | | 318 |<---------------------->| | 319 | | | 320 ~ ~ ~ 321 | Access Resources | | 322 |<---------------------->| | 323 | | | 325 Figure 1: High-level OAuth process flow 327 4.1. General Requirements and Assumptions 329 There are a number of authentication relationships that need to be in 330 place before OAuth can be used to delegate authorization. Client 331 authentication is critical for preventing unauthorized parties from 332 gaining access: The Client MUST be able to authenticate to both the 333 Server and the Resource Owner. Moreover, the Client MUST be able to 334 authenticate the same identifier to both parties (e.g., using the 335 same certificate in the context of HTTPS), so that the Server and the 336 Resource Owner can verify that the Client that the RO authorizes is 337 the same one that the Server will enable to access the protected 338 resources. 340 Likewise the Resource Owner MUST be able to authenticate both to 341 Server and to the Client, and it MUST be able to authenticate the 342 same identifier to both (it may have other identifiers with each). 343 The Server MUST be able to authenticate both to the Client and the 344 RO, but it is not required to use the same identity for both. 346 [[ Editor's note: The requirements that the Client and RO use the 347 same identifiers across multiple relationships can be onerous, but is 348 required to combat the Client and RO collusion attacks discussed in 349 Section 5.3, as are the identity checks by the RO and the Client that 350 take advantage of these identifiers (in Section 4.3.3 and 351 Section 4.4). If WG discussions indicate that either or both of 352 these attacks are not to be addressed by this model, then the 353 identity requirements and the corresponding checks can be removed; 354 for now, they are listed as MUST-level requirements. ]] 356 All messages in this process SHOULD be integrity- and 357 confidentiality-protected; ones that MUST be so protected are noted 358 below. The security of the authorization process relies only on the 359 authentication relationships above, but access to some parameters 360 passed between OAuth entities could allow third parties to disrupt 361 the OAuth process. 363 4.2. Request token issuance 365 Client Server Resource Owner 366 | | | 367 | req-token-request | | 368 1. |----------------------->| | 369 | | | 370 | req-token-issue | | 371 | (req-t) | | 372 2. |<-----------------------| | 373 | | | 375 The OAUth process is initiated by a Client that wishes to access a 376 given set of resources on the Server. The authorization flow begins 377 when the Client sends a request for a Request Token to the Server. 378 In response to this request, the Server MUST authenticate the Client. 379 If authentication is unsuccessful, the process fails. If 380 authentication succeeds, the Server MUST generate a random request 381 token and store a binding between the request token and authenticated 382 identity of the Client (denoted Cl-ID below). During this 383 transaction, the Client and the Server MAY negotiate the resources to 384 which access is to be granted. 386 Upon receiving a request token from the Server, the Client MUST 387 authenticate the Server and store a binding between the Server's 388 authenticated identity and the request token. 390 The Request Token identifies a Client's request for authorization to 391 access resources on the Server. At issuance, the token is bound to a 392 Client identity and a Server identity. To uniquely identify an 393 authorization transaction, the Server MUST ensure that each Request 394 Token is unique within the set of such tokens that it issues. Token 395 values SHOULD be difficult for an outside entity to guess. In order 396 to avoid resource exhaustion at the Server, it is RECOMMENDED that 397 Request Tokens have a limited lifetime. 399 4.3. Authorization of the request 401 Before the Client can access protected resources, it must be 402 authorized to access those resources: The Client must request 403 authorization, the Resource Owner must notify the Server that it 404 intends to grant access, and then the Resource Owner must actually 405 grant access to the Client. In addition, before the Resource Owner 406 grants access, it must assure that the Client's request is authentic 407 by validating it with the Server. 409 4.3.1. Request for authorization 411 Client Server Resource Owner 412 | | | 413 | | request-authz | 414 | | (req-t) | 415 3. |------------------------------------------------>| 416 | | | 418 The Client requests authorization to access resources by sending a 419 message to the Resource Owner that contains an unused request token. 420 After sending a request token in an authorization request, the Client 421 MUST mark that request token as used, and MUST NOT use the request 422 token in any subsequent authorization request. 424 If the Client wishes to verify that the RO that it interacts with on 425 this step is the same entity that it interacts with later, then it 426 MUST authenticate the RO and store a binding between the request 427 token and the RO's authenticated identity (in addition to the binding 428 to the Server's identity recorded earlier). It should be noted 429 however, that these steps are purely optional. They provide no 430 additional security guarantees with respect to the authorizations 431 granted; they only allow the Client to track which request tokens 432 have been used. (In the presence of session continuity mechanisms, 433 such as HTTP cookies, this authentication may be used as the basis 434 for the authentication required at the time of notification of 435 authorization, described in Section 4.3.3.) 437 Note that this transaction does not require the RO to authenticate 438 the Client. The Client will be authenticated in a later step, after 439 the RO is told by the Server which Client identity is bound to the 440 request token. 442 4.3.2. Verification token issuance 444 Client Server Resource Owner 445 | | | 446 | | ver-token-request | 447 | | (req-t) | 448 4. | |<-----------------------| 449 | | | 450 | | ver-token-issue | 451 | | (ver-t,cl-id,scope) | 452 5. | |----------------------->| 453 | | | 455 The Resource Owner validates the request for authorization and 456 obtains the ability to grant authorization by requesting a 457 verification token from the Server. This request MUST include the 458 request token provided by the Client. Before sending this request, 459 the RO SHOULD authenticate the Server, since a false Server can 460 disrupt the authorization process (but not cause unintended 461 authorization to be granted). 463 When the Server receives a request for a verification token, it MUST 464 take the following actions, in order: 466 1. Authenticate the Resource Owner and verify that the RO owns the 467 resources subject to authorization 469 2. Verify that the request token has not been used in a prior 470 request. If so, the process fails; if not, the request token is 471 marked as used. 473 3. Generate a random verification token that is unique in the scope 474 of such tokens 476 4. Store a binding between the verification token, the Client 477 identity bound to the request token, and the RO's authenticated 478 identity 480 5. Establish an integrity- and confidentiality-protected channel to 481 the RO (if one does not already exist, e.g., the channel used the 482 request) 484 6. Send a message to the RO containing the following information: 486 * The verification token 487 * The Client identity bound to the request token 489 * The scope of the authorization to be provided (i.e., the set 490 of resources) 492 The Server and the RO MAY also perform further negotiation of the 493 scope of the authorization at this point. 495 It should be emphasized that the Server MUST NOT transmit the 496 verification token over any channel that is not authenticated, 497 integrity-protected, and confidentiality-protected, since the 498 verification token is highly sensitive information: Any third party 499 that intercepts the verification token is capable of granting the 500 Client access to the protected resources, and any party that can 501 inject or modify a verification token can cause the RO to grant 502 unintended accesses. 504 Upon receiving the Server's message (authenticating the Server again, 505 if necessary), the RO stores a binding between the verification token 506 and the Client identity provided by the Server. 508 Some might note that there is an asymmetry to the security 509 requirements for the two halves of this transaction: The request for 510 a verification token is only authenticated, while the response also 511 needs to be confidentiality- and integrity-protected. This is 512 because the injection of a false request token can only cause the 513 process to fail (since the Client identity provided by the server 514 will be wrong), while leakage of the verification token can cause 515 used to grant an unintended authorization. For simplicity, it is 516 RECOMMENDED that the same channel (with full protections) be used for 517 the request and the response. 519 Note that at this point in the process, no authorization has been 520 granted. The Server has only issued the Resource Owner a 521 verification token so that the RO can grant authorization if desired. 522 The Server MUST NOT provide the Client access to protected resources 523 until the RO has provided the verification token to the Client, and 524 Client has exchanged the verification token for an access token, as 525 described below. 527 4.3.3. Notification of authorization 529 Client Server Resource Owner 530 | | | 531 | authz-notify | | 532 | (ver-t,req-t) | | 533 6. |<------------------------------------------------| 534 | | | 536 If the Resource Owner decides to authorize the Client to access 537 protected resources (the set bound to the verification token), then 538 it signals this by sending a message to the Client containing the 539 verification token. Before sending such a message, the RO MUST 540 authenticate the Client and establish an integrity- and 541 confidentiality-protected (i.e., encrypted) channel to the 542 authenticated Client. If the authenticated identity of the Client 543 does not match the Client identity bound to the verification token, 544 or if the authentication fails, then the process fails and the RO 545 MUST NOT send the verification token to the Client. As above, the RO 546 MUST NOT transmit the verification token over any channel that is not 547 authenticated, integrity-protected, and confidentiality-protected. 549 Upon receipt of an authorization notification message, the Client 550 MUST authenticate the RO and store a binding between the RO's 551 authenticated identity and the verification token. The Client MUST 552 also store a binding between the verification token and the Server 553 identity bound to the request token. The Client MAY verify that the 554 RO's authenticated identity matches the one bound earlier to the 555 request token. 557 4.4. Access token issuance 559 Client Server Resource Owner 560 | | | 561 | acc-token-request | | 562 | (ver-t) | | 563 7. |----------------------->| | 564 | | | 565 | acc-token-issue | | 566 | (acc-t,ro-id) | | 567 8. |<-----------------------| | 568 | | | 570 The Client obtains access to the designated resources by exchanging a 571 verification token that it has received for an access token. To 572 request an access token, the Client sends the verification token to 573 the Server. Before sending this message, the Client MUST 574 authenticate the Server and verify that the authenticated Server 575 identity is the one bound to the verification token (i.e., the Server 576 identity that the Client originally bound to the request token). 578 Upon receiving a request for an access token, the Server MUST 579 authenticate the Client and verify (1) that the verification token 580 provided is one that it issued, and (2) that the Client's 581 authenticated identity matches the identity bound to the verification 582 token. If both criteria are satisfied, then the Server MUST generate 583 a random access token (unique within the scope of such tokens) and 584 store a binding between the access token, the Client's authenticated 585 identity, the RO identity bound to the verification token, and the 586 resources bound to the verification token. 588 The Server completes the authorization process by sending to the 589 Client a message containing (1) the access token and (2) an 590 identifier for the RO to which the verification token was issued. 591 The Client MUST authenticate the Server prior to accepting such a 592 message and verify that the Server's identity matches that bound to 593 the request token and verification token. The Client MUST also 594 verify that the RO identity returned by the Server matches the RO 595 identity bound to the verification token. If both verifications 596 succeed, then the Client stores a binding between the access token 597 and the protected resources. 599 Note that because the Client received the verification token over a 600 confidentiality-protected channel, the Server's acceptance of the 601 verification token provides the Client assurance that the entity that 602 provided the verification token was authorized (at the Server) to 603 grant the specified authorization. 605 4.5. Accessing protected resources 607 Client Server Resource Owner 608 | | | 609 | acc-res-request | | 610 | (acc-t) | | 611 9. |----------------------->| | 612 | | | 613 | resources | | 614 |<-----------------------| | 615 | | | 617 Finally, once a Client is authorized to access resources on the 618 Server, it accesses them using the corresponding access token. When 619 a Client wishes to access resources, it sends a request to the Server 620 containing the access token. The Server MUST authenticate the Client 621 and verify that the access token presented belongs to the 622 authenticated Client before responding with the requested resources. 624 4.6. Summary 626 All of the interactions above are summarized in Figure 4, below. 627 Figure 2 and Figure 3 illustrate the life-cycles of the request token 628 and the verification token, respectively. 630 1. Issues token +--------+ +--------+ 2. Uses token 631 4. Provides info | Server |------------->| Client | request authz 632 to validate +--------+ +--------+ 633 (Client ID) | ^ | 634 | | +----------+ | 635 | +-----| Resource |<----+ 636 +------>| Owner | 637 +----------+ 638 3. Uses token to request 639 verification token 641 Figure 2: Life cycle of a request token 643 1. Issues token +--------+ +--------+ 2. Uses token 644 4. Provides info | Server |<-------------| Client | request 645 to validate +--------+------------->+--------+ access tok. 646 (RO ID) | ^ 647 | +----------+ | 648 +---->| Resource |-----+ 649 | Owner | 650 +----------+ 651 3. Uses token to 652 grant authz 654 Figure 3: Life cycle of a verification token 656 Client Server Resource Owner 657 | | | 658 | req-token-request | | 659 1. |----------------------->| | 660 | | | 661 | req-token-issue | | 662 | (req-t) | | 663 2. |<-----------------------| | 664 | | | 665 | | request-authz | 666 | | (req-t) | 667 3. |------------------------------------------------>| 668 | | | 669 | | ver-token-request | 670 | | (req-t) | 671 4. | |<-----------------------| 672 | | | 673 | | ver-token-issue | 674 | | (ver-t,cl-id,scope) | 675 5. | |----------------------->| 676 | | | 677 | authz-notify | | 678 | (ver-t,req-t) | | 679 6. |<------------------------------------------------| 680 | | | 681 | acc-token-request | | 682 | (ver-t) | | 683 7. |----------------------->| | 684 | | | 685 | acc-token-issue | | 686 | (acc-t,ro-id) | | 687 8. |<-----------------------| | 688 | | | 689 ~ ~ ~ 690 | acc-res-request | | 691 | (acc-t) | | 692 9. |----------------------->| | 693 | | | 694 | resources | | 695 |<-----------------------| | 696 | | | 698 Figure 4: OAuth message flow 700 5. Security analysis 702 As described in the design goals above, the OAuth model aims to 703 protect against four general classes of threat: 705 1. Outside intervention in an otherwise honest transaction 707 2. Malicious actors within the authorization process 709 3. Collusion among actors within the authorization process 711 4. Denial of service against the authorization process 713 In this section, we discuss how the model described above addresses 714 each class of threat. 716 5.1. Protection from outside interference 718 The authentication requirements of the OAuth process prevent outside 719 entities from interfering with the process. This property means that 720 if each party assumes that the other authenticated parties behave as 721 the process specifies, all three parties are assured that the genuine 722 RO has authorized the Client to access the specified resources on the 723 Server, i.e., that no outside actors have corrupted the process. 724 (The next section discusses how the parties can be sure that 725 misbehaving actors cannot create unintended authorizations.) 727 The Server's assurance comes from its knowledge of the token bindings 728 and its confidence in the authenticated identities of the Client and 729 the RO. The Server is assured of the Client's identity because the 730 Client authenticated that identity when it requested the request 731 token and when it exchanged the verification token for the access 732 token. The Server is assured that the genuine RO authorized the 733 Client because it received the verification token from the Client, 734 and because it knows that it only issued the verification token to 735 the genuine RO (and because it trusts that the RO only gives the 736 verification token to parties it intends to authorize). 738 The RO is assured that it knows the real identity of the authorized 739 Client because it has verified that the identity that the Server will 740 provide access to (provided by the server with the verification 741 token) is the same as the authenticated identity of the Client that 742 the RO gave the verification token to. The RO is also assured that 743 no other Client has received the verification token because it 744 transmitted that token only over an authenticated, confidentiality- 745 protected channel. (Of course, the RO knows that it is the genuine 746 owner of the subject resources.) 747 The Client is assured that the Server from which it will receive 748 resources is the same as the Server it requested authorization from 749 by the persistence of the Server's identity between the requests for 750 the request token and the access token (and subsequent requests for 751 resources). The Client knows that the RO is the genuine RO because 752 it has verified that the authenticated identity of the RO matches the 753 genuine RO identity provided by the Server. The Client knows that it 754 is the intended recipient of the authorization because the Server 755 accepts the verification token in a request authenticated with the 756 Client's identity (i.e., because the Server only accepts verification 757 tokens submitted with the identity bound to the verification token). 759 5.2. Protection from malicious actors within the model 761 The OAuth model ensures that the process fails (i.e., no 762 authorization is granted) if any actor in the process acts 763 improperly. Here we consider the avenues for misbehavior available 764 to each role, and discuss how the model prevents them from having ill 765 effects. Of course, since the Server is trusted, it can subvert the 766 process by granting access to any party, so we do not consider its 767 behavior in any further detail. 769 The RO performs two actions in the protocol that it might attempt to 770 exploit to create unauthorized accesses: First it sends request 771 tokens to the server to obtain verification tokens, and second, it 772 sends verification tokens to the Client to grant access. Because the 773 Server verifies that the RO owns the subject resources before it 774 issues a verification token, a RO cannot obtain a verification token 775 for resources it does not own. Moreover, once an RO has obtained a 776 verification token for resources, that token can only be used by the 777 Client that requested the request token; the RO cannot use it to 778 grant access to any other Client. So a malicious RO cannot use the 779 OAuth process to grant access beyond its ownership, or beyond the 780 intended Client. 782 In order to obtain access to protected resources, a Client needs to 783 obtain a verification token bound to its identity and the protected 784 resources. However, verification tokens are only issued to the 785 genuine RO, and only bound to the Client identity that the Server 786 associates with a request token. So the only way for a Client to 787 obtain access without violating the authentication constraints of the 788 model (i.e., forging an authentication or obtaining another Client's 789 private authentication key) is to obtain a request token with its own 790 Client identity, and convince the genuine RO to authorize this 791 request token -- namely, to go through the proper OAuth procedure. 792 So the only risk from misbehaving Clients is from social engineering 793 attacks against the RO (e.g., phishing). 795 5.3. Protection from colluding actors 797 It is possible for multiple actors within the OAuth process to 798 collude in order to subvert the process. There are six possible 799 combinations of roles, including multiple actors in the same role: 801 1. Server -- Server 803 2. Server -- Client 805 3. Server -- RO 807 4. Client -- RO 809 5. Client -- Client 811 6. RO -- RO 813 Of these, we need only consider the latter three, since collusion 814 with the Server is irrelevant (the Server can simply provide the 815 desired accesses or resources). 817 Since a legitimate Client and RO can already allow the Client access 818 to the RO's resources, the only remaining objective for such a 819 collusion would be to convince the Server that access was really 820 being granted to another Client. This attack, however, is prevented 821 by the requirement that the Client authenticate all its interactions 822 with the Server: The RO can only grant access to a Client identity 823 bound to a request token, and that binding is established by a 824 transaction in which the Client's identity is authenticated. 826 Two Clients cannot by themselves obtain any access, so two colluding, 827 unauthorized Clients do no damage (neither can present a request 828 token that will result in an authorization). However, if one Client 829 is authorized (say C1), the other (C2) might try to use it to gain 830 access, in the following way: C2 could register a token for itself, 831 pass that token to C1, and have C1 request authorization. If the RO 832 fails to verify that the Client identity bound to the request token 833 (provided by the Server) matches the identity of the requesting 834 Client, then the RO will return the verification token to C1. C1 can 835 then pass the verification token to C2, who can then obtain an access 836 token and access resources. On the other hand, if the Client does 837 perform the specified verification that the two identities match, 838 then the risk that this collusion will result in unintended access is 839 removed. 841 In a similar vein, the major risk from colluding ROs is that they 842 convince the Client that any given colluding RO is the proper owner 843 of resources than any other colluding RO owns. (It is a given that 844 they can grant access to their own resources, and there are no 845 attacks available against the Server, since it has authoritative 846 knowledge.) To accomplish this attack, when the Client requests 847 authorization from one RO (say RO1), that RO passes the request token 848 to another RO (RO2). RO2 then acquires a verification token and 849 passes it back to RO1, who uses it to notify the Client. If the 850 Client fails to compare RO1's authenticated identity to the identity 851 bound to the verification token (provided by the Server), then the 852 Client will think that RO1 is the owner of resources that actually 853 belong to RO2. On the other hand, if the client does perform this 854 check (as required), then this risk is eliminated. 856 5.4. Protection from denial of service 858 The successful completion of the OAuth process is dependent on using 859 tokens to communicate bindings between identities and authorizations. 860 Entities that can inject false tokens of any type can therefore cause 861 the process to fail (false in the sense that they are not bound to 862 any identity at the server). The model is secured against this type 863 of denial of service attack because senders of information are 864 authenticated where necessary, and because messages are integrity- 865 protected to prevent tampering en route. 867 The OAuth process allows the Client and the RO to force the Server to 868 maintain state, in the form of bindings between request and 869 verification tokens and other information. The requirement for the 870 server to maintain this state information makes it vulnerable to 871 resource exhaustion attacks. The Server can mitigate this risk by 872 imposing a limited life-time on request tokens and verification 873 tokens, at the risk that an OAuth process that is not completed 874 within the life-time of the appropriate tokens will fail. 876 6. Acknowledgements 878 This document is essentially an abstraction and security analysis of 879 the current OAuth protocol [1]. We are thus deeply in debt to the 880 authors of that protocol, especially Eran Hammer-Lahav, who provided 881 several helpful explanations of the current OAuth protocol 882 specification as this document was being developed. 884 7. IANA Considerations 886 This memo makes no request to IANA. 888 8. Security Considerations 890 This document describes a security model for delegated authorization, 891 especially in the World Wide Web context. As such, security 892 considerations are discussed in detail throughout. 894 9. Normative References 896 [1] Hammer-Lahav, E. and B. Cook, "The OAuth Core Protocol", 897 draft-hammer-oauth-02 (work in progress), March 2009. 899 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 900 Levels", BCP 14, RFC 2119, March 1997. 902 [3] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 903 August 2007. 905 Authors' Addresses 907 Richard Barnes 908 BBN Technologies 909 9861 Broken Land Parkway 910 Columbia, MD 21046 911 US 913 Phone: +1 410 290 6169 914 Email: rbarnes@bbn.com 916 Matthew Lepinski 917 BBN Technologies 918 10 Moulton St 919 Cambridge, MA 02138 920 US 922 Phone: +1 617 873 5939 923 Email: mlepinski@bbn.com