idnits 2.17.1 draft-ietf-oauth-use-cases-02.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '...tion method that MAY be used for such ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2012) is 4213 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-oauth-v2-threatmodel-07 == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-05 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-14 == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-bearer-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAUTH WG G. Fletcher 3 Internet-Draft AOL 4 Intended status: Informational T. Lodderstedt 5 Expires: April 13, 2013 Deutsche Telekom AG 6 Z. Zeltsan 7 Alcatel-Lucent 8 October 10, 2012 10 OAuth Use Cases 11 draft-ietf-oauth-use-cases-02 13 Abstract 15 This document lists the OAuth use cases. The provided list is based 16 on the Internet Drafts of the OAUTH working group and discussions on 17 the group's mailing list. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 13, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Native Application . . . . . . . . . . . . . . . . . . . . 6 58 2.4. In-App-Payment (based on Native Application) . . . . . . . 8 59 2.5. Device with an input method . . . . . . . . . . . . . . . 10 60 2.6. Client password (shared secret) credentials . . . . . . . 12 61 2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12 62 2.8. Access token exchange . . . . . . . . . . . . . . . . . . 13 63 2.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 15 64 2.10. Gateway for browser-based VoIP applets . . . . . . . . . . 17 65 2.11. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 66 2.12. Signature with asymmetric secret . . . . . . . . . . . . . 20 67 3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 22 68 4. Security considerations . . . . . . . . . . . . . . . . . . . 22 69 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 76 1. Introduction 78 This document describes the use cases that have been discussed on the 79 oauth WG mailing list and introduced by the Internet Drafts submitted 80 to the group. The selected use cases illustrate the use of the OAuth 81 flows by the clients of the various profiles and types. The document 82 also includes those cases that are not directly supported by the 83 OAuth 2.0 [I-D.ietf-oauth-v2], but were considered during its 84 development. The document provides a list of the requirements 85 derived from the use cases. The use cases supported by OAuth 2.0 are 86 indicated. 88 The document's objective is to help with understanding of the OAuth 89 2.0 protocol design. 91 The following section provides the abbreviated descriptions of the 92 use cases. 94 2. OAuth use cases 96 This section describes the use cases that have been discussed by the 97 oauth WG. 99 2.1. Web server 101 Description: 103 Alice accesses an application running on a web server at 104 www.printphotos.example.com and instructs it to print her photographs 105 that are stored on a server www.storephotos.example.com. The 106 application at www.printphotos.example.com receives Alice's 107 authorization for accessing her photographs without learning her 108 authentication credentials with www.storephotos.example.com. 110 Pre-conditions: 112 o Alice has registered with www.storephotos.example.com to enable 113 authentication 115 o The application at www.printphotos.example.com has established 116 authentication credentials with the application at 117 www.storephotos.example.com 119 Post-conditions: 121 A successful procedure results in the application 122 www.printphotos.example.com receiving an authorization code from 123 www.storephotos.example.com. The code is bound to the application at 124 www.printphotos.example.com and to the callback URL supplied by the 125 application. The application at www.printphotos.example.com uses the 126 authorization code for obtaining an access token from 127 www.storephotos.example.com. The application at 128 www.storephotos.example.com issues an access token after 129 authenticating the application at www.printphotos.example.com and 130 validating the authorization code that it has submitted. The 131 application at www.printphotos.example.com uses the access token for 132 getting access to Alice's photographs at www.storephotos.example.com. 134 Note: When an access token expires, the service at 135 www.printphotos.example.com needs to repeat the OAuth procedure for 136 getting Alice's authorization to access her photographs at 137 www.storephotos.example.com. Alternatively, if Alice wants to grant 138 the application a long lasting access to her resources at 139 www.storephotos.example.com, the authorization server associated with 140 www.storephotos.example.com may issue the long-living tokens. Those 141 tokens can be exchanged for short-living access tokens required to 142 access www.storephotos.example.com. 144 Requirements: 146 o The server www.printphotos.example.com, which hosts an OAuth 147 client, must be capable of issuing the HTTP redirect requests to 148 Alice's user agent - a browser 150 o Application at www.storephotos.example.com must be able to 151 authenticate Alice. The authentication method is not in the OAuth 152 scope 154 o Application at www.storephotos.example.com must obtain Alice's 155 authorization of the access to her photos by 156 www.printphotos.example.com 158 o Application at www.storephotos.example.com may identify to Alice 159 the scope of access that www.printphotos.example.com has requested 160 while asking for Alice's authorization 162 o Application at www.storephotos.example.com must be able to 163 authenticate the application at www.printphotos.example.com and 164 validate the authorization code before issuing an access token. 165 The OAuth 2.0 protocol [I-D.ietf-oauth-v2] specifies one 166 authentication method that MAY be used for such authentication - 167 Client Password Authentication. 169 o Application at www.printphotos.example.com must provide a callback 170 URL to the application at www.storephotos.example.com (note: the 171 URL can be pre-registered with www.storephotos.example.com) 173 o Application at www.storephotos.example.com is required to maintain 174 a record that associates the authorization code with the 175 application at www.printphotos.example.com and the callback URL 176 provided by the application 178 o Access tokens are bearer's tokens (they are not associated with a 179 specific application, such as www.printphotos.example.com) and 180 should have a short lifespan 182 o Application at www.storephotos.example.com must invalidate the 183 authorization code after its first use 185 o Alice's manual involvement in the OAuth authorization procedure 186 (e.g., entering an URL or a password) should not be required. 187 (Alice's authentication to www.storephotos.example.com is not in 188 the OAuth scope. Her registration with 189 www.storephotos.example.com is required as a pre-condition) 191 Note: OAuth 2.0 supports this use case 193 2.2. User-agent 195 Description: 197 Alice has on her computer a gaming application. She keeps her scores 198 in a database of a social site at www.fun.example.com. In order to 199 upload Alice's scores, the application gets access to the database 200 with her authorization. 202 Pre-conditions: 204 o Alice uses a gaming application implemented in a scripting 205 language (e.g., JavaScript) that runs in her browser and uses 206 OAuth for accessing a social site at www.fun.example.com 208 o There is no a web site supporting this application and capable of 209 handling the OAuth flow, so the gaming application needs to update 210 the database itself 212 o The application is registered with the social site at 213 www.fun.example.com and has an identifier 215 o Alice has registered with www.fun.example.com for identification 216 and authentication 218 o An auxiliary web server at www.help.example.com is reachable by 219 Alice's browser and capable of providing a script that extracts an 220 access token from an URL's fragment 222 Post-conditions: 224 A successful procedure results in Alice's browser receiving an access 225 token. The access token is received from www.fun.example.com as a 226 fragment of a redirection URL of an auxiliary web server 227 www.help.example.com. Alice's browser follows the redirection, but 228 retains the fragment. From the auxiliary web server at 229 www.help.example.com Alice's browser downloads a script that extracts 230 access token from the fragment and makes it available to the gaming 231 application. The application uses the access token to gain access to 232 Alice's data at www.fun.example.com. 234 Requirements: 236 o Registration of the application running in the Alice's browser 237 with the application running on www.fun.example.com is required 238 for identification 240 o Alice's authentication with www.fun.example.com is required 242 o Application running at www.fun.example.com must be able to 243 describe to Alice the request made by the gaming application 244 running on her computer and obtain Alice's authorization for or 245 denial of the requested access 247 o After obtaining Alice's authorization the application running at 248 www.fun.example.com must respond with an access token and redirect 249 Alice's browser to a web server (e.g., www.help.example.com) that 250 is capable of retrieving an access token from an URL 252 Note: OAuth 2.0 supports this use case 254 2.3. Native Application 256 Description: 258 Alice wants to upload (or download) her photographs to (or from) 259 storephotos.example.com using her smartphone. She downloads and 260 installs a photo app on her smartphone. In order to enable the app 261 to access her photographs, Alice needs to authorize the app to access 262 the web site on her behalf. The authorization shall be valid for a 263 prolonged duration (e.g. several months), so that Alice does not need 264 to authenticate and authorize access on every execution of the app. 265 It shall be possible to withdraw the app's authorization both on the 266 smartphone as well as on the site storephotos.example.com. 268 Pre-conditions: 270 o Alice has installed a (native) photo app application on her 271 smartphone 273 o The installed application is registered with the social site at 274 storephotos.example.com and has an identifier 276 o Alice holds an account with storephotos.example.com 278 o Authentication and authorization shall be performed in an 279 interactive, browser-based process. The smartphone's browser is 280 used for authenticating Alice and for enabling her to authorize 281 the request by the Mobile App 283 Post-conditions: 285 A successful procedure results in Alice's app receiving the access 286 and refresh tokens. The app obtains the tokens by utilizing the 287 Authorization Code flow. The application uses the access token to 288 gain access to Alice's data at storephotos.example.com. The refresh 289 tokens are persistently stored on the device for use in subsequent 290 app executions. If a refresh token exists on app startup, the app 291 directly uses the refresh token to obtain a new access token. 293 Requirements: 295 o Alice's authentication with storephotos.example.com is required 297 o Registration of the application running on Alice's smartphone is 298 required for identification and registration and may be carried 299 out on a per installation base 301 o The application at storephotos.example.com provides a capability 302 to view and delete the apps' authorizations. This implies that 303 the different installations of the same app on the different 304 devices can be distinguished (e.g., by a device name or a 305 telephone number) 307 o The app must provide Alice an option to logout. The logout must 308 result in revocation of the refresh tokens on the authorization 309 server 311 Note: OAuth 2.0 supports this use case 313 2.4. In-App-Payment (based on Native Application) 315 Description: 317 Alice has installed on her computer a gaming application (e.g., 318 running as native code or as a widget). At some point she wants to 319 play the next level of the game and needs to purchase an access to 320 the advanced version of the game from her service provider at 321 www.sp.example.com. With Alice's authorization the application 322 accesses her account at www.sp.example.com and enables her to make 323 the payment. 325 Pre-conditions: 327 o Alice has registered and has an account with her service provider 328 at www.sp.example.com 330 o The application is registered with the service provider at 331 www.sp.example.com. This enables the server provider to provide 332 Alice with all necessary information about the gaming application 333 (including the information about the purchasing price) 335 o Alice has a Web user-agent (e.g., a browser or a widget runtime) 336 installed on her computer 338 Post-conditions: 340 A successful procedure results in the gaming application invoking the 341 user browser and directing it to the authorization server of the 342 service provider. The HTTP message includes information about the 343 gaming application's request to access Alice's account. The 344 authorization server presents to Alice the authentication and 345 authorization interfaces. The authorization interface shows Alice 346 the information about the application's request including the 347 requested charge to her account. After Alice successfully 348 authenticates and authorizes the request, the authorization server 349 enables Alice to save the transaction details including the 350 authorization code issued for the gaming application. Then the 351 authorization server redirects Alice's browser to a custom scheme URI 352 (registered with the operating system). This redirection request 353 contains a one-time authorization code and invokes a special 354 application that is able to extract the authorization code and 355 present it to the gaming application. The gaming application 356 presents the authorization code to the authorization server and 357 exchanges it for a one-time access token. The gaming application 358 then uses the access token to get access to Alice's account and post 359 the charges at www.sp.example.com. 361 Requirements: 363 Note: The focus is on the requirements that are specific to this use 364 case. The requirements that are common to the native applications 365 are listed in the preceding use case. 367 o An authorization server associated with the server at 368 www.sp.example.com must be able to provide Alice with information 369 about the access request that the gaming application has made 370 (including the amount that is to be charged to her account with 371 the service provider and the purpose for the charge) over a secure 372 transport 374 o An authorization server associated with the server at 375 www.sp.example.com must be able to obtain Alice's authorization 376 decision on the request over a secure transport 378 o An authorization server associated with the server at 379 www.sp.example.com must be able to generate on demand a one-time 380 authorization code and a one-time access token according to the 381 scope authorized by Alice 383 o An authorization server associated with the server at 384 www.sp.example.com must be able to call back to the gaming 385 application with the authorization result over a secure transport 387 o An authorization server associated with the server at 388 www.sp.example.com must enable the gaming application to exchange 389 an authorization code for an access token over a secure transport 391 o An authorization server associated with the server at 392 www.sp.example.com must verify the authorization code and 393 invalidate it after its first use 395 o An authorization server associated with the server at 396 www.sp.example.com must enable Alice to save the details of the 397 requested transaction, including the authorization code 399 o An authorization server associated with the server at 400 www.sp.example.com must keep a record linking the requested 401 transaction with the authorization code and the respective access 402 token 404 o An authorization server associated with the server at 405 www.sp.example.com must enable the resource server 406 www.sp.example.com to obtain the transaction information that is 407 linked to the issued access token 409 o Resource server at www.sp.example.com must verify access token and 410 invalidate it after its first use 412 o A resource server at www.sp.example.com must enable the gaming 413 application to post charges to Alice's account according to the 414 access token presented over a secure transport 416 o The gaming application must provide a custom scheme URI to the 417 authorization server associated with www.sp.example.com (note: it 418 can be preregistered with the authorization server) 420 o Alice's manual involvement in the OAuth authorization procedure 421 (e.g., entering an URL or a password) should not be required. 422 (Alice's authentication to www.sp.example.com is not in the OAuth 423 scope) 425 Note: OAuth 2.0 does not directly support this use case 427 2.5. Device with an input method 429 Description: 431 Alice has a device, such as a gaming console, that does not support 432 an easy data-entry method. She also has access to a computer with a 433 browser. The application running on the Alice's device gets 434 authorized access to a protected resource (e.g., photographs) stored 435 on a server at www.storephotos.example.com 437 Pre-conditions: 439 o Alice uses a gaming console, which does not have an easy data- 440 entry method, for accessing her photographs at 441 www.storephotos.example.com 443 o Alice is able to connect to www.storephotos.example.com using a 444 computer that runs a browser 446 o Auhtorization server associated with www.storephotos.example.com 447 is able to generate an authorization code that is suitable for 448 reading and writing by a human (e.g., an alphanumeric string that 449 is not too long) 451 o The gaming device supports input of the characters that can be 452 found in an authorization code 454 o Alice has registered with the authorization server associated with 455 www.storephotos.example.com for identification and authentication 457 Post-conditions: 459 o Alice, interacting with an authorization server associated with 460 www.storephotos.example, authorizes access to her photographs by 461 her gaming console. She uses her browser-equipped computer for 462 OAuth authorization 464 o The authorization server associated with 465 www.storephotos.example.com responds to Alice's authorization by 466 displaying an authorization code in her browser's window 468 o Alice enters the displayed code into an input field on the gaming 469 console 471 o The gaming console exchanges with the authorization server the 472 authorization code for an access token 474 o Alice's gaming console uses the access token to access the 475 photographs on www.storephotos.example.com 477 Requirements: 479 o Alice's authentication with the authorization server is required 481 o Alice is required to perform authorization of her gaming console 482 by interacting with the authorization server associated with 483 www.storephotos.example.com. To that end she has to direct her 484 browser to the authorization server 486 o After authorizing the access and getting an authorization code 487 displayed in her browser, Alice has to enter the displayed code 488 into an input field on the gaming console 490 o The gaming console should be able to exchange the authorization 491 code for an access token through interaction with the 492 authorization server associated with www.storephotos.example.com 494 o The URL of the authorization server and the authorization code 495 must be suitable for manual entry 497 o The authorization code must be composed of the characters that are 498 appropriate for input to the gaming console 500 o Because the authorization code is relatively short and its 501 character set is limited, the code's lifetime should be configured 502 appropriately 504 Note: OAuth 2.0 supports this use case 506 2.6. Client password (shared secret) credentials 508 Description: 510 The company GoodPay prepares the employee payrolls for the company 511 GoodWork. In order to do that the application at 512 www.GoodPay.example.com gets authenticated access to the employees' 513 attendance data stored at www.GoodWork.example.com. 515 Pre-conditions: 517 o The application at www.GoodPay.example.com has established through 518 a registration an identifier and a shared secret with the 519 application running at www.GoodWork.example.com 521 o The scope of the access by the application at 522 www.GoodPay.example.com to the data stored at 523 www.GoodWork.example.com has been defined 525 Post-conditions: 527 A successful procedure results in the application at 528 www.GoodPay.example.com receiving an access token after 529 authenticating to the application running at 530 www.GoodWork.example.com. 532 Requirements: 534 o Authentication of the application at www.GoodPay.example.com to 535 the application at www.GoodWork.example.com is required 537 o The authentication method must be based on the identifier and 538 shared secret, which the application running at 539 www.GoodPay.example.com submits to the application at 540 www.GoodWork.example.com in the initial HTTP request 542 o Because in this use case GoodPay gets access to GoodWork's 543 sensitive data, GoodWork shall have a pre-established trust with 544 GoodPay on the security policy and the authorization method's 545 implementation 547 Note: OAuth 2.0 supports this use case 549 2.7. Assertion 551 Description: 553 Company GoodPay prepares the employee payrolls for the company 554 GoodWork. In order to do that the application at 555 www.GoodPay.example.com gets authenticated access to the employees' 556 attendance data stored at www.GoodWork.example.com. 557 This use case describes an alternative solution to the one described 558 by the use case Client password credentials. 560 Pre-conditions: 562 o The application at www.GoodPay.example.com has obtained an 563 authentication assertion from a party that is trusted by the 564 application at www.GoodWork.example.com 566 o The scope of the access by the application at 567 www.GoodPay.example.com to the data stored at 568 www.GoodWork.example.com has been defined 570 o The application at www.GoodPay.example.com has established trust 571 relationship with the asserting party and is capable of validating 572 its assertions 574 Post-conditions: 576 A successful procedure results in the application at 577 www.GoodPay.example.com receiving an access token after 578 authenticating to the application running at www.GoodWork.example.com 579 by presenting an assertion (e.g., SAML assertion). 581 Requirements: 583 o Authentication of the application at www.GoodPay.example.com to 584 the application at www.GoodWork.example.com is required 586 o The application running at www.GoodWork.example.com must be 587 capable of validating assertion presented by the application 588 running at www.GoodPay.example.com 590 o Because in this use case GoodPay gets access to GoodWork's 591 sensitive data, GoodWork shall establish trust with GoodPay on the 592 security policy and the authorization method's implementation 594 Note: OAuth 2.0 supports this use case 596 2.8. Access token exchange 598 Description: 600 Alice uses an application running on www.printphotos.example.com for 601 printing her photographs that are stored on a server at 602 www.storephotos.example.com. The application running on 603 www.storephotos.example.com, while serving the request of the 604 application at www.printphotos.example.com, discovers that some of 605 the requested photographs have been moved to 606 www.storephotos1.example.com. The application at 607 www.storephotos.example.com retrieves the missing photographs from 608 www.storephotos1.example.com and provides access to all requested 609 photographs to the application at www.printphotos.example.com. The 610 application at www.printphotos.example.com carries out Alice's 611 request. 613 Pre-conditions: 615 o The application running on www.printphotos.example.com is capable 616 of interacting with Alice's browser 618 o Alice has registered with and can be authenticated by 619 authorization server 621 o The applications at www.storephotos.example.com has registered 622 with authorization server 624 o The applications at www.storephotos1.example.com has registered 625 with authorization server 627 o The application at www.printphotos.example.com has registered with 628 authorization server 630 Post-conditions: 632 A successful procedure results in the application at 633 www.printphotos.example.com receiving an access token that allows 634 access to Alice's photographs. This access token is used for the 635 following purposes: 637 o By the application running at www.printphotos.example.com to get 638 access to the photographs at www.storephotos.example.com 640 o By the application running at www.storephotos.example.com to 641 obtain from authorization server another access token that allows 642 it to retrieve the additional photographs stored at 643 www.storephotos1.example.com 645 As the result, there are two access token issued for two different 646 applications. The tokens may have different properties (e.g., scope, 647 permissions, and expiration dates). 649 Requirements: 651 o The applications at www.printphotos.example.com and 652 www.storephotos.example.com require different access tokens 654 o The application at www.printphotos.example.com is required to 655 provide its callback URL to the application at 656 www.storephotos.example.com 658 o Authentication of the application at www.printphotos.example.com 659 to the authorization server is required 661 o Alice's authentication by the authorization server is required 663 o The authorization server must be able to describe to Alice the 664 request of the application at www.printphotos.example.com and 665 obtain her authorization (or rejection) 667 o If Alice has authorized the request, the authorization server must 668 be able to issue an access token that enables the application at 669 www.printphotos.example.com to get access to Alice's photographs 670 at www.storephotos.example.com 672 o The authorization server must be able, based on the access token 673 presented by the application at www.printphotos.example.com, to 674 generate another access token that allows the application at 675 www.storephotos.example.com to get access to the photographs at 676 www.storephotos1.example.com. In this context the authorization 677 server must validate the authorization of the application at 678 www.storephotos.example.com to obtain the token. 680 o The application at www.storephotos.example.com must be able to 681 validate an access token presented by the application running at 682 www.printphotos.example.com 684 o The application at www.storephotos1.example.com must be able to 685 validate the access token presented by the application running at 686 www.storephotos.example.com 688 Note: This use case is indirectly supported by Assertion frmamework 689 for OAuth 2.0 [I-D.ietf-oauth-assertions] and its extensions SAML 2.0 690 Bearer Assertion Profiles for OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] 691 and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 692 [I-D.ietf-oauth-jwt-bearer] 694 2.9. Multiple access tokens 696 Description: 698 Alice uses a communicator application running on a web server at 699 www.communicator.example.com to access her email service at 700 www.email.example.com and her voice over IP service at 701 www.voip.example.com. Email addresses and telephone numbers are 702 obtained from Alice's address book at www.contacts.example.com. 703 Those web sites all rely on the same authorization server, so the 704 application at www.communicator.example.com can receive a single 705 authorization from Alice for getting access to these three services 706 on her behalf at once. 707 The authorization server needs to issue different access tokens for 708 the involved services due to security and privacy policy. One 709 typical reason is the use of the symmetric secrets for signing self- 710 contained access tokens. In this use case, using a particular token 711 for more than a single service introduces a security risk. 713 Note: This use case is especially useful for native applications 714 since a web browser needs to be launched only once. 716 Pre-conditions: 718 o The same authorization server serves Alice and all involved 719 servers 721 o Alice has registered with the authorization server for 722 authentication and for authorization of the requests of the 723 communicator application running at www.communicator.example.com 725 o The email application at www.email.example.com has registered with 726 the authorization server for authentication 728 o The VoIP application at www.voip.example.com has registered with 729 the authorization server for authentication 731 o The address book at www.contacts.example.com has registered with 732 the authorization server for authentication 734 Post-conditions: 736 A successful procedure results in the application at 737 www.communicator.example.com receiving three different access tokens: 738 one for accessing the email service at www.email.example.com, one for 739 accessing the contacts at www.contacts.example.com, and one for 740 accessing the VoIP service at www.voip.example.com. 742 Requirements: 744 o The application running at www.communicator.example.com must be 745 authenticated by the authorization server 747 o Alice must be authenticated by the authorization server 749 o The application running at www.communicator.example.com must be 750 able to get a single Alice's authorization for access to the 751 multiple services (e.g., email and VoIP) 753 o The application running at www.communicator.example.com must be 754 able to recognize that all three applications rely on the same 755 authorization server 757 o A callback URL of the application running at 758 www.communicator.example.com must be known to the authorization 759 server 761 o The authorization server must be able to issue the separate 762 service-specific tokens (with different, scope, permissions, and 763 expiration dates) for access to the requested services (such as 764 email and VoIP) 766 Note: OAuth 2.0 does not support this use case 768 2.10. Gateway for browser-based VoIP applets 770 Description: 772 Alice accesses a social site on a web server at 773 www.social.example.com. Her browser loads a VoIP applet that enables 774 her to make a VoIP call using her SIP server at 775 www.sipservice.example.com. The application at 776 www.social.example.com gets Alice's authorization to use her account 777 with www.sipservice.example.com without learning her authentication 778 credentials with www.sipservice.example.com. 780 Pre-conditions: 782 o Alice has registered with www.sipservice.example.com for 783 authentication 785 o The application at www.social.example.com has established 786 authentication credentials with the application at 787 www.sipservice.example.com 789 Post-conditions: 791 A successful procedure results in the application at 792 www.social.example.com receiving access token from 793 www.sipservice.example.com with Alice's authorization. 795 Requirements: 797 o The server at www.social.example.com must be able to redirect 798 Alice's browser to www.sipservice.example.com 800 o The application running at www.sipservice.example.com must be 801 capable of authenticating Alice and obtaining her authorization of 802 a request from www.social.example.com 804 o The server at www.sipservice.example.com must be able to redirect 805 Alice's browser back to www.social.example.com 807 o The application at www.social.example.com must be able to 808 translate the messages of the Alice's VoIP applet into SIP and RTP 809 messages 811 o The application at www.social.example.com must be able to add the 812 access token to the SIP requests that it sends to 813 www.sipservice.example.com 815 o Application at www.sipservice.example.com must be able to 816 authenticate the application at www.social.example.com and 817 validate the access token 819 o Alice's manual involvement in the OAuth authorization procedure 820 (e.g., entering an URL or a password) should not be required. 821 (Alice's authentication to www.sipservice.example.com is not in 822 the OAuth scope) 824 Note: OAuth 2.0 does not support this use case 826 2.11. Signed Messages 828 Description: 830 Alice manages all her personal health records in her personal health 831 data store at a server at www.myhealth.example.com, which manages 832 authorization of access to Alice's participating health systems. 833 Alice's Primary Care Physician (PCP), which has a Web site at 834 www.pcp.example.com, recommends her to see a sleep specialist 835 (www.sleepwell.example.com). Alice arrives at the sleep specialist's 836 office and authorizes it to access her basic health data at her PCP's 837 web site. The application at www.pcp.example.com verifies that Alice 838 has authorized www.sleepwell.example.com to access her health data as 839 well as enforces that www.sleepwell.example.com is the only 840 application that can retrieve that data with that specific 841 authorization. 843 Pre-conditions: 845 o Alice has a personal health data store that allows for discovery 846 of her participating health systems (e.g. psychiatrist, sleep 847 specialist, PCP, orthodontist, ophthalmologist, etc) 849 o The application at www.myhealth.example.com manages authorization 850 of access to Alice's participating health systems 852 o The application at www.myhealth.example.com can issue 853 authorization tokens understood by Alice's participating health 854 systems 856 o The application at www.pcp.example.com stores Alice's basic health 857 and prescription records 859 o The application at www.sleepwell.com stores results of Alice's 860 sleep tests 862 Post-conditions: 864 o A successful procedure results in just the information that Alice 865 authorized being transferred from the Primary Care Physician 866 (www.pcp.example.com) to the sleep specialist 867 (www.sleepwell.example.com) 869 o The transfer of health data only occurs if the application at 870 www.pcp.example.com can verify that www.sleepwell.example.com is 871 the party requesting access and that the authorization token 872 presented by www.sleepwell.example.com is issued by the 873 application at www.myhealth.example.com with a restricted audience 874 of www.sleepwell.example.com 876 Requirements: 878 o The application at www.sleepwell.example.com interacting with 879 www.myhealth.example.com must be able to discover the location of 880 the PCP system (e.g., XRD discovery) 882 o The application at www.sleepwell.example.com must be capable of 883 requesting Alice's authorization of access to the application at 884 www.pcp.example.com for the purpose of retrieving basic health 885 data (e.g. date-of-birth, weight, height, etc). The mechanism 886 Alice uses to authorize this access is out of scope for this use 887 case 889 o The application at www.myhealth.example.com must be capable of 890 issuing a token bound to www.sleepwell.example.com for access to 891 the application at www.pcp.example.com. Note that a signed token 892 (JWT) can be used to prove who issued the token 894 o The application at www.sleepwell.example.com must be capable of 895 issuing a request (which includes the token issued by 896 www.myhealth.example.com) to the application at 897 www.pcp.example.com 899 o The application at www.sleepwell.example.com must sign the request 900 before sending it to www.pcp.example.com 902 o The application at www.pcp.example.com must be capable of 903 receiving the request and verifying the signature 905 o The application at www.pcp.example.com must be capable of parsing 906 the message and finding the authorization token 908 o The application at www.pcp.example.com must be capable of 909 verifying the signature of the authorization token 911 o The application at www.pcp.example.com must be capable of parsing 912 the authorization token and verifying that this token was issued 913 to the application at www.sleepwell.com 915 o The application at www.pcp.example.com must be capable of 916 retrieving the requested data and returning it to the application 917 at www.sleepwell.example.com 919 Note: OAuth 2.0 does not support this use case 921 2.12. Signature with asymmetric secret 923 Description: 925 Alice accesses an application running on a web server at 926 www.printphotos.example.com and instructs it to print her photographs 927 that are stored on a server www.storephotos.example.com. The 928 application at www.printphotos.example.com, which does not have a 929 shared secret with www.storephotos.example.com, receives Alice's 930 authorization for accessing her photographs without learning her 931 authentication credentials with www.storephotos.example.com. 933 Pre-conditions: 935 o Alice has registered with www.storephotos.example.com to enable 936 authentication 938 o The application at www.printphotos.example.com has a private and a 939 matching public keys 941 Post-conditions: 943 A successful procedure results in the application at 944 www.printphotos.example.com receiving an access token from 945 www.storephotos.example.com for accessing the Alice's photographs. 947 Requirements: 949 o The application at www.printphotos.example.com must be capable of 950 issuing the HTTP redirect requests to Alice's user agent - a 951 browser 953 o The application at www.storephotos.example.com must be able to 954 authenticate Alice 956 o The application running at www.storephotos.example.com must be 957 able to obtain the public key of the application at 958 www.printphotos.example.com 960 o The application running at www.printphotos.example.com is required 961 to sign using its private key the requests to the application at 962 www.storephotos.example.com 964 o The application at www.storephotos.example.com must obtain Alice's 965 authorization of the access to her photos by 966 www.printphotos.example.com 968 o The application at www.storephotos.example.com is required to 969 identify to Alice the scope of access that 970 www.printphotos.example.com has requested while asking for Alice's 971 authorization 973 o The application at www.storephotos.example.com must be able to 974 authenticate the application at www.printphotos.example.com by 975 validating a signature of its request using the public key of 976 www.printphotos.example.com 978 o The application at www.printphotos.example.com must provide a 979 callback URL to the application at www.storephotos.example.com 980 (note: the URL can be pre-registered with 981 www.storephotos.example.com) 983 o The application at www.storephotos.example.com must be capable of 984 issuing the HTTP redirect requests to Alice's browser 986 o Alice's manual involvement in the OAuth authorization procedure 987 (e.g., entering an URL or a password) should not be required. 988 (Alice's authentication to www.storephotos.example.com is not in 989 the OAuth scope) 991 Note: OAuth 2.0 does not support this use case 993 3. Authors of the use cases 995 The major contributors of the use cases are as follows: 997 W. Beck, Deutsche Telekom AG 998 G. Brail, Sonoa Systems 999 B. de hOra 1000 B. Eaton, Google 1001 S. Farrell, NewBay Software 1002 G. Fletcher, AOL 1003 Y. Goland, Microsoft 1004 B. Goldman, Facebook 1005 E. Hammer-Lahav, Yahoo! 1006 D. Hardt 1007 R. Krikorian, Twitter 1008 T. Lodderstedt, Deutsche Telekom 1009 E. Maler, PayPal 1010 D. Recordon, Facebook 1011 L. Shepard, Facebook 1012 A. Tom, Yahoo! 1013 B. Vrancken, Alcatel-Lucent 1014 Z. Zeltsan, Alcatel-Lucent 1016 4. Security considerations 1018 The OAuth 2.0 specification [I-D.ietf-oauth-v2] provides the 1019 implementers with security guidelines for all OAuth 2.0 client 1020 profiles. In addition, a comprehensive OAuth security model and 1021 background for the protocol design are provided by 1022 [I-D.ietf-oauth-v2-threatmodel]. 1024 5. IANA considerations 1026 This Internet Draft includes no request to IANA. 1028 6. Acknowledgements 1030 The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable 1031 help with preparing this document. Special thanks are to the draft 1032 reviewers Thomas Hardjono and Melinda Shore, whose suggestions have 1033 helped to improve the draft. 1035 7. References 1037 7.1. Normative References 1039 [I-D.ietf-oauth-v2] 1040 Hardt, D., "The OAuth 2.0 Authorization Framework", 1041 draft-ietf-oauth-v2-31 (work in progress), August 2012. 1043 7.2. Informative References 1045 [I-D.ietf-oauth-v2-threatmodel] 1046 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 1047 Threat Model and Security Considerations", 1048 draft-ietf-oauth-v2-threatmodel-07 (work in progress), 1049 August 2012. 1051 [I-D.ietf-oauth-assertions] 1052 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 1053 "Assertion Framework for OAuth 2.0", 1054 draft-ietf-oauth-assertions-05 (work in progress), 1055 September 2012. 1057 [I-D.ietf-oauth-saml2-bearer] 1058 Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion 1059 Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-14 1060 (work in progress), September 2012. 1062 [I-D.ietf-oauth-jwt-bearer] 1063 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 1064 (JWT) Bearer Token Profiles for OAuth 2.0", 1065 draft-ietf-oauth-jwt-bearer-02 (work in progress), 1066 September 2012. 1068 Authors' Addresses 1070 George Fletcher 1071 AOL 1073 Email: gffletch@aol.com 1075 Torsten Lodderstedt 1076 Deutsche Telekom AG 1078 Email: torsten@lodderstedt.net 1080 Zachary Zeltsan 1081 Alcatel-Lucent 1082 600 Mountain Avenue 1083 Murray Hill, New Jersey 1084 USA 1086 Phone: +1 908 582 2359 1087 Email: Zachary.Zeltsan@alcatel-lucent.com