OAUTH WG Z. Zeltsan Internet-Draft Alcatel-Lucent Intended status: Informational May 18, 2010 Expires: November 19, 2010 OAuth Use Cases draft-zeltsan-use-cases-oauth-00 Abstract This document lists the OAuth use cases. The document's objective is to identify the use cases that will be a base for deriving the OAuth requirements. The provided list is based on the Internet-Drafts and other OAuth-related documents that have been discussed by the participants of the oauth working group. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 19, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zeltsan Expires November 19, 2010 [Page 1] Internet-Draft OAuth Use Cases May 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 3. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Use cases of the draft The OAuth 2.0 Protocol . . . . . . 3 3.1.1. User-Agent Flow . . . . . . . . . . . . . . . . . . . 3 3.1.2. Web Server Flow . . . . . . . . . . . . . . . . . . . 4 3.1.3. Device Flow . . . . . . . . . . . . . . . . . . . . . 5 3.1.4. Username and Password Flow . . . . . . . . . . . . . . 6 3.1.5. Client Credentials Flow . . . . . . . . . . . . . . . 7 3.1.6. Assertion Flow . . . . . . . . . . . . . . . . . . . . 7 3.2. Use case of the draft Using OAuth for Recursive Delegation . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Content sharing . . . . . . . . . . . . . . . . . . . 8 3.3. Use cases of the draft Evaluating OAUTH's suitability for SIP authentication . . . . . . . . . . . . . . . . . . 9 3.3.1. Establishment of an MSRP session . . . . . . . . . . . 9 3.3.2. Gateway for browser-based VoIP applets . . . . . . . . 10 3.4. Use case Access Token Exchange . . . . . . . . . . . . . . 11 3.5. Use case for signature with asymmetric secret . . . . . . 12 4. Authors of the use cases . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Zeltsan Expires November 19, 2010 [Page 2] Internet-Draft OAuth Use Cases May 2010 1. Introduction The need for documenting the OAuth use cases was discussed at the oauth WG virtual meetings, on the group's mailing list, and at the IETF 77. This Internet-Draft describes such use cases. The objective of the draft is to initiate discussion that will lead to defining a set of the use cases that the OAuth specifications should support. The following section provides the abbreviated descriptions of the use cases. The descriptions include the pointers to the sources of the use cases. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. OAuth use cases This section lists the major use cases that have been discussed by the oauth WG. 3.1. Use cases of the draft The OAuth 2.0 Protocol [draft-ietf-oauth-v2] 3.1.1. User-Agent Flow Description: A Client application residing in a user-agent accesses protected resource on user's behalf (This use case covers the one specified in section Rich App Profile of [draft-hardt-oauth]) Pre-conditions: o Client is an application residing in a user-agent, typically implemented in a browser using a scripting language such a JavaScript o Client is capable of interacting with the user-agent o Client provides redirection URL to authorization server for redirecting the user-agent after authorization by the end user Zeltsan Expires November 19, 2010 [Page 3] Internet-Draft OAuth Use Cases May 2010 o Client's authentication by authorization server is based on the user-agent's same origin policy (client cannot keep client secret confidential) o Client does not need to be an HTTP server o End user's registration with authorization Server for identification and authentication is required o End user's authentication to authorization server is required but not specified o User-agent is a web browser capable of executing a server-provided script to extract an access token from the response of the authorization server. User-agent passes the access token to the client Involved entities: o Resource owner: end user o Web Server that stores a protected resource o Authorization server o Client o User-agent 3.1.2. Web Server Flow Description: A client, which is a part of the web server application, accesses protected resource on user's behalf. User does not need to share authentication credentials with the client. (This use case covers the one specified in section Web App Profile of [draft-hardt-oauth] and in [RFC5849]) Pre-conditions: o Client is a Web application capable of interacting with the user- agent (typically a browser) and receiving requests from the authorization server (i.e., capable of acting as HTTP server) o Client's registration with authorization server for identification and authentication is required Zeltsan Expires November 19, 2010 [Page 4] Internet-Draft OAuth Use Cases May 2010 o Client provides its callback URL to the authorization server o Client authentication to authorization server is required; it is based on a client identifier and shared secret o End user's registration with authorization server for identification and authentication is required o End user's authentication to authorization server is required but not specified Involved entities: o Resource owner: end user o Server that stores a protected resource o Authorization server o Client 3.1.3. Device Flow Description: A Client executing on a device that does not have an easy data-entry method accesses a protected resource on user's behalf. (This use case covers the one described in the message submitted to OAUTH-WG list by Brent Goldman, Facebook on 3/11/2010) Pre-conditions: o A Client is running on a device that does not have an easy data- entry method (e.g. game consoles or media server). The client is able to poll the authorization server until the end user completes the authorization process o Client's registration with authorization server for identification is required o Client's interaction with user-agent requires end user's involvement (i.e., manual data entry by the end user) o End user's registration with authorization server for identification and authentication is required o End user's authentication to authorization server is required but not specified Zeltsan Expires November 19, 2010 [Page 5] Internet-Draft OAuth Use Cases May 2010 o The End user has a separate access to a user-agent on another computer or device (e.g. home computer, a laptop, or a smartphone) Involved entities: o Resource owner: end user o Server that stores a protected resource o Authorization server o Client o User-agent 3.1.4. Username and Password Flow Description: A trusted client accesses the end user's resource on her or his behalf using the end user's username and password The client does not need to store the end user's username and password permanently (This use case covers those specified in [draft-dehora-farrell-oauth-accesstoken-creds] and in section Client Account and Password Profile of [draft-hardt-oauth]) Pre-conditions: o A client is capable of obtaining the username and password from the end user o Client's registration with authorization server for identification and authentication is required o Client's authentication to authorization server is based on client identifier and client secret o Client's authorization is based on its knowledge of the end user's username and password o Client is not required to be an HTTP server (i.e., does not need to do HTTP redirection) o End user's registration with authorization server for identification and authentication is required o End user's authentication to authorization server is based on username and password Zeltsan Expires November 19, 2010 [Page 6] Internet-Draft OAuth Use Cases May 2010 o End user's involvement is not needed Involved entities: o Resource owner: end user o Server that stores a protected resource o Authorization server o Client 3.1.5. Client Credentials Flow Description: A client that is not acting on behalf of a separate resource owner accesses a protected resource (This use case covers the one specified in section Client Account and Password Profile of [draft-hardt-oauth]) Pre-conditions: o Client has established a client identifier and a client secret (that assumed to be of high-entropy since it does not need to be memorized by an end user) o Client's registration with authorization server for identification and authentication is required o Client's authentication to the authorization server is based on the client identifier and shared secret o End user involvement is not needed Involved entities: o Server that stores a protected resource o Authorization server o Client 3.1.6. Assertion Flow Description: A client exchanges an existing assertion (e.g., SAML assertion) for an access token, which it uses to access the protected resource. The Zeltsan Expires November 19, 2010 [Page 7] Internet-Draft OAuth Use Cases May 2010 client could be the resource owner or could be acting on the resource owner's behalf (This use case covers the one specified in section Assertion Profile of [draft-hardt-oauth]) Pre-conditions: o Client has obtained an assertion from an asserting entity o Client's registration with authorization server is not required o End user involvement is not needed o Authorization server is able to validate the assertion issued by the asserting entity Involved entities: o Asserting entity o Authorization server o Client o Server that stores a protected resource 3.2. Use case of the draft Using OAuth for Recursive Delegation [draft-vrancken-oauth-redelegation] 3.2.1. Content sharing Description: Enable organizing and sharing information among the end users. For example, a Web user (resource owner) can grant data access to a pre-defined set of users. This can be done with the use of a special OAuth client - content manager - which serves as a proxy between the end-users and the Web servers that host the resources related to the project. The content manager allows a user (the owner of the resources) to specify a set of the resources related to a project (e.g., by tagging) and a set of the clients and their access rights in respect to the resources. The content manager may also enable searching of the related materials. Pre-conditions: Zeltsan Expires November 19, 2010 [Page 8] Internet-Draft OAuth Use Cases May 2010 o First client is a client that has been authorized by the resource owner - an end user - to grant access rights for the protected resource to the second client o Second client is a client that wishes to get authorization of the first client to get access to the protected resource o Clients' registration with Web server for identification and authentication is required o Clients' authentication to authorization (Web) server is required and based on their identifiers and shared secrets o Clients need to be the HTTP servers (i.e., be capable of HTTP redirection) o End user's authentication to Web server is required but not specified Involved entities: o Resource owner: end user o First client o Second client o Server that stores a protected resource 3.3. Use cases of the draft Evaluating OAUTH's suitability for SIP authentication [draft-beck-oauth-sip-eval] 3.3.1. Establishment of an MSRP session Description: A client that implements text chat using asynchronous HTTP requests accesses on behalf of an end user her or his protected resources on a SIP server Pre-conditions: o The resource owner is an end user that has a SIP account and uses chat service that is implemented as asynchronous HTTP requests o Protected resource is data associated with end user's SIP account on her or his SIP server, which is capable to participate in OAuth Zeltsan Expires November 19, 2010 [Page 9] Internet-Draft OAuth Use Cases May 2010 exchange o A client is a Web application that implements text chat service using asynchronous HTTP requests, implements also the OAuth client, and is capable of translating the chat-related HTTP requests into SIP and MSRP messages o client's registration with authorization server for identification and authentication is required o Client's authentication by authorization server is required o Client is an HTTP server (i.e., it is capable of redirecting end user's user-agent) Involved entities: o Resource owner o SIP server that stores protected resource o Client 3.3.2. Gateway for browser-based VoIP applets Description: A client that implements a VoIP client as a browser applet accesses the end user's SIP resources on her or his SIP server and on the end user's behalf Pre-conditions: o Resource owner is an end user that has a SIP account and uses VoIP Web service that is implemented as a browser applet o SIP server that is capable to participate in OAuth exchange and stores data associated with end user's SIP account o A client is a Web application that implements VoIP as a browser applet, implements also the OAuth client, and is capable of translating the Web applets messages into SIP and RTP o client's registration with authorization server for identification and authentication is required o Client' authentication by authorization server is required Zeltsan Expires November 19, 2010 [Page 10] Internet-Draft OAuth Use Cases May 2010 o Client needs to be an HTTP server (i.e., is capable of redirecting end user's user-agent) Involved entities: o Resource owner o SIP server o Client 3.4. Use case Access Token Exchange (submitted to OAUTH-WG list by Torsten Lodderstedt, Deutsche Telekom on 4/6/2010) Description: A client performs on an end user's behalf multi-layered services (i.e., the services where one service requires execution of another service that requires authentication) Pre-conditions: o Authorization server is capable of issuing access tokens to the client and multiple and dependent Web services o Client's authentication by authorization server is required o Authorization of (N-1)th Web service for execution of Nth service is based on the content of the access token obtained by the client o Requirements to the registration of the client and the dependent Web services are to be defined o Requirements to the end user's registration with client are to be defined o Requirements for the end user's authentication by the client are to be defined Involved entities: o Resource owner o Client that initiates the first Web service o First Web service that requires execution of the second Web service Zeltsan Expires November 19, 2010 [Page 11] Internet-Draft OAuth Use Cases May 2010 o Nth Web service that is a service that requires execution of the (N-1)th Web service o Authorization server o Servers that store the protected resources 3.5. Use case for signature with asymmetric secret (submitted to OAUTH-WG list by Eran Hammer-Lahav, Yahoo! on 2/18/ 2010) Description: A client, that does not have a shared secret with a server storing a protected resource, accesses the protected resource on end user's behalf Pre-conditions: o A client does not share a secret with a server that stores a protected resource, but has a public key o client's registration with authorization server for identification and authentication is not required o Client's authentication by the Web server is required and based on the public key cryptography o Web Server that stores a protected resource has access to the client's public key and associated information o Requirements to the End user's involvement are to be determined o Requirements to the client being an HTTP server are to be determined Involved entities: o Resource owner: end User o Client o Server that stores a protected resource Zeltsan Expires November 19, 2010 [Page 12] Internet-Draft OAuth Use Cases May 2010 4. Authors of the use cases The major contributors of the use cases are as follows: W. Beck, Deutsche Telekom AG G. Brail, Sonoa Systems B. de hOra B. Eaton, Google S. Farrell, NewBay Software Y. Goland, Microsoft B. Goldman, Facebook E. Hammer-Lahav, Yahoo! D. Hardt R. Krikorian, Twitter T. Lodderstedt, Deutsche Telekom E. Maler, PayPal D. Recordon, Facebook L. Shepard, Facebook A. Tom, Yahoo! B. Vrancken, Alcatel-Lucent Z. Zeltsan, Alcatel-Lucent 5. Security Considerations TBD 6. IANA Considerations This Internet Draft includes no request to IANA. 7. Acknowledgements The author thanks Igor Faynberg and Hui-Lan Lu for their invaluable help with preparing this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Zeltsan Expires November 19, 2010 [Page 13] Internet-Draft OAuth Use Cases May 2010 8.2. Informative References [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010, . [draft-hardt-oauth] Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", January 2010, . [draft-ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Protocol", April 2010, . [draft-vrancken-oauth-redelegation] Vrancken, B. and Z. Zeltsan, "Using OAuth for Recursive Delegation", February 2010, . [draft-beck-oauth-sip-eval] Beck, W., "Evaluating OAUTH's suitability for SIP authentication", October 2009, . [draft-dehora-farrell-oauth-accesstoken-creds] de hOra, B. and S. Farrell, "OAuth Access Tokens using credentials", February 2010, . Author's Address Zachary Zeltsan Alcatel-Lucent 600 Mountain Avenue Murray Hill, New Jersey USA Phone: +1 908 582 2359 Email: Zachary.Zeltsan@alcatel-lucent.com Zeltsan Expires November 19, 2010 [Page 14]