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, <http://www.ietf.org/rfc/rfc5849.txt>.
[draft-hardt-oauth]
Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web
Resource Authorization Profiles", January 2010,
<http://tools.ietf.org/html/draft-hardt-oauth-01>.
[draft-ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Protocol", April 2010,
<http://tools.ietf.org/html/draft-ietf-oauth-v2-04>.
[draft-vrancken-oauth-redelegation]
Vrancken, B. and Z. Zeltsan, "Using OAuth for Recursive
Delegation", February 2010, <https://datatracker.ietf.org/
doc/draft-vrancken-oauth-redelegation/>.
[draft-beck-oauth-sip-eval]
Beck, W., "Evaluating OAUTH's suitability for SIP
authentication", October 2009, <http://tools.ietf.org/id/
draft-beck-oauth-sip-eval-00.txt>.
[draft-dehora-farrell-oauth-accesstoken-creds]
de hOra, B. and S. Farrell, "OAuth Access Tokens using
credentials", February 2010, <http://www.ietf.org/id/
draft-dehora-farrell-oauth-accesstoken-creds-02.txt>.
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]