OAUTH WG B. Vrancken
Internet-Draft Z. Zeltsan
Intended status: Informational Alcatel-Lucent
Expires: March 5, 2010 September 2009
Using OAuth for Recursive Delegation
draft-vrancken-oauth-redelegation-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a use case for delegating authorization by a
Resource Owner to another user via a Client using the OAuth protocol.
OAuth allows Clients to access server resources on behalf of another
Vrancken & Zeltsan Expires March 5, 2010 [Page 1]
Internet-Draft Using OAuth for Recursive Delegation September 2009
party (such as a different Client or an end-user). This document
describes the use of OAuth for delegating one Client's authorization
to another Client - a scenario, which is also known as four-legged
authorization.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Use of the OAuth protocol for re-delegation of the access
rights for a protected resource . . . . . . . . . . . . . . . 3
3.1. Redirection-Based Authorization . . . . . . . . . . . . . 4
3.2. The Resource Owner authorizes a first Client to share
a resource . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. The first Client authorizes access to the resource by
the second Client . . . . . . . . . . . . . . . . . . . . 5
4. Multi-layered delegation of authorization . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Unlimited recursive delegation . . . . . . . . . . . . . . 8
5.2. Phishing Attack . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Other examples . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Vrancken & Zeltsan Expires March 5, 2010 [Page 2]
Internet-Draft Using OAuth for Recursive Delegation September 2009
1. Introduction
The need for documenting a use case for the OAuth multi-layered
authorization was discussed on the OAuth mailing list and at the bar
BoF meeting at the IETF 75. This Internet Draft describes such a use
case. We propose this document as a work item of the OAuth working
group. Depending on the group's decision it can become a part of
another Internet Draft or a separate document.
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. Use of the OAuth protocol for re-delegation of the access rights for
a protected resource
The OAuth protocol provides a method for servers to allow third-party
access to protected resources without forcing their end-users to
reveal their authentication credentials. This method can be employed
to support 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 users and their access rights in
respect to the resources. The content manager may also enable
searching of the related materials.
The methods for managing user information are out of the scope of
this document. The document describes how such content manager
authorizes user access to the resources using the OAuth protocol.
As far as authorization is concerned, the content manager and the
user with whom the Resource Owner shares a resource are the OAuth
Clients as defined in [draft-ietf-oauth-authentication]. In this
document the content manager, which has been authorized by a Resource
Owner to share a resource with a user is called first Client. The
user with whom the resource is to be shared is referred to as a
second Client.
This document describes the use of OAuth for enabling sharing a
Vrancken & Zeltsan Expires March 5, 2010 [Page 3]
Internet-Draft Using OAuth for Recursive Delegation September 2009
resource under the following scenario:
o First Client has been authorized by the Resource Owner, to share a
resource (e.g., file) with a second Client.
o The first Client has obtained access token credentials for the
resource.
o The first Client enables the second Client to access the resource
without getting the Resource Owner involved in authorization
process.
3.1. Redirection-Based Authorization
OAuth uses a set of token credentials to represent the authorization
granted to the Client by the Resource Owner. Typically, token
credentials are issued by the Server at the Resource Owner's request,
after authenticating the Resource Owner's identity using its Server
credentials (usually a username and password pair).
The specification [draft-ietf-oauth-web-delegation] defines a method
for provisioning the token credentials with the use of the HTTP
redirection and the Resource Owner's user agent. This document
describes how the method can be expanded to allow a Client to share a
resource with another Client after obtaining the Resource Owner's
authorization to do so.
The specification [draft-ietf-oauth-web-delegation] defines the
following URIs of a Web Server:
o Temporary Credential Request
o Resource Owner Authorization
o Token Request
It also defines the HTTP methods (GET, POST, etc.) used to make the
requests. This specification relies on these definitions.
The method in which the server advertises its three endpoints is
beyond the scope of [draft-ietf-oauth-web-delegation] and this
document.
3.2. The Resource Owner authorizes a first Client to share a resource
In the initial stage of the authorization procedure, the Resource
Owner authorizes a Client to share the resource with another user(who
is just another Client in terms of
Vrancken & Zeltsan Expires March 5, 2010 [Page 4]
Internet-Draft Using OAuth for Recursive Delegation September 2009
[draft-ietf-oauth-web-delegation]).
The first Client obtains (after the Resource Owner's authorization)
token credentials that allow it to access (e.g., read, update) the
resource. In the described use case the access rights include a
right to re-delegate (i.e., to proxy) the obtained authorization.
The first Client, which does not need to access the resource, will
use the credentials for authenticating to the Server and authorizing
access by the second Client.
The first Client obtains token credentials using a mechanism
specified in [draft-ietf-oauth-web-delegation]. The steps that
follow are illustrated by Figure 1 below and described in the next
section.
3.3. The first Client authorizes access to the resource by the second
Client
This section describes the steps of the procedure that follow the
initial steps:
o Resource Owner has requested the first Client to share a resource
with another user - a second Client
o The first Client has obtained the token credentials from the
Server for the resource.
+-------------+ +----------+ +------------+
| 1st Client | |Web server| |2nd Clientt |
+------+------+ +-----+----+ +------+-----+
| 1. 1st Client notifies the | |
| 2nd Client of | |
| the resource sharing | |
|-----------------------------+------------------>|
| | |
| | |
| |2. Request resource|
| |<------------------|
| | |
| |3. 401, auth. fail |
| |------------------>|
| | |
| | |
| | 4. Establish |
| | consumer_key and |
| | secret |
| |<----------------->|
Vrancken & Zeltsan Expires March 5, 2010 [Page 5]
Internet-Draft Using OAuth for Recursive Delegation September 2009
| | |
| |5. Request |
| |temporary |
| |credentials |
| |<------------------|
| | |
| | |
| | |
| |6. Temporary |
| |credentials (token |
|7. 2nd Client asks the 1st |T, secret Ts) |
|Client to grant access to the|------------------>|
|resource on the Web server. | |
|The request includes T | |
||<----------------------------+-------------------|
|| 7. | |
v|---------------------------->| |
| | |
| +------+------+ |
| | | |
| |Authenticate | |
| |and get | |
| |authorization| |
| +------+------+ |
| | |
|8. Redirect 1st Client back | |
|to the 2nd | |
||<----------------------------| |
|| | |
||8. | |
v+-----------------------------+------------------>|
| | |
| |
|9. Request token |
|credentials |
|<------------------|
|10. Get token |
|credentials |
+------------------>|
|11. Request |
|resource |
|<------------------|
| |
| 12. Provide the |
| resource |
+------------------>|
Vrancken & Zeltsan Expires March 5, 2010 [Page 6]
Internet-Draft Using OAuth for Recursive Delegation September 2009
Figure 1 - Authorization by the first Client of the second Client to
obtain access to a resource
1. The first Client notifies the second Client that a resource
available for sharing on the server. The first client MUST
provide full path URL to the resource on the Web server.
2. The second client requests access to the resource.
3. The Web server responds with 401 HTTP error code denying access
to the protected resource.
4. The second client establishes oauth_consumer_key and a shared
secret - the client credentials - as specified in
[draft-ietf-oauth-authentication].
5. The second Client requests temporary credentials as specified in
[draft-ietf-oauth-web-delegation].
6. The second client receives from the Web server the temporary
credentials.
7. The second Client asks the first Client to grant access to the
requested resource on the Web server.
After this step the first Client authenticates itself to the
Web server and authorizes (or denies) access to the resource
by the second Client. To demonstrate that it has been
authorized by the Resource Owner to access the resource, the
first Client uses its token credentials obtained as a result
of the usual OAuth procedure. To do that, the first Client
forms a request to the Web Server for the protected resource
as specified in [draft-ietf- oauth-authentication] and
[draft-ietf-oauth-delegation] with a modification. The
purpose of the required modification is to inform the Web
Server that the first Client intends to use its token
credentials for proving that it is authorized by the Resource
Owner to access the resource and for authorizing access by
another party, but not for getting the resource itself.
8. After the first Client has authorized access to the resource for
the second Client, the Web server sends a URL containing the
oauth_token and oauth_verifier parameters as specified in
[draft-ietf-oauth-web-delegation].
After this step the first client responds back to the second
client, confirming that the authorization has been done.
Vrancken & Zeltsan Expires March 5, 2010 [Page 7]
Internet-Draft Using OAuth for Recursive Delegation September 2009
9. The second Client requests the token credentials (specified in
[draft-ietf-oauth-web-delegation]).
10. The Web server responds with the token credentials.
11. The second Client requests access to the protected resource as
specified in [draft-ietf-oauth-web-delegation].
12. After verification the Web Server satisfies the request.
4. Multi-layered delegation of authorization
Section 3 describes how one Client (i.e., first Client) can grant
access to a resource to another Client (i.e., second Client). The
described method can be extended for granting access by the Nth
Client to a client N+1. In such a scenario each Client has to have a
list of all Clients that are permitted to access the resource.
Indeed, the second Client, after obtaining authorization from the
first Client, can notify a third Client (assuming that it is on the
list) of the intent to share the resource (as did the first Client in
step 1). Then by repeating the rest of the procedure described in
section 3, the third Client can obtain authorization to the resource.
The procedure can be repeated N times resulting in the recursive
delegation of authorization.
In general, the procedure allows a Client N+1 to demonstrate to the
Web server that it has been authorized by an Nth Client to access the
resource. Before making authorization the Nth Client MUST verify
that the Client N+1 is on the list of the Clients that are permitted
to access the resource.
5. Security Considerations
As stated in [RFC2617], the greatest sources of risks are usually
found not in the core protocol itself but in policies and procedures
surrounding its use. Implementers are strongly encouraged to assess
how this protocol addresses their security requirements. Because of
the nature of multi-layer delegation, the same security
considerations are applicable as in the single-layer delegation
[draft-ietf-oauth-web-delegation].
5.1. Unlimited recursive delegation
Resource owners should be able to decide if the client may use
recursive delegation. Clients should inform the resource owner, at
Vrancken & Zeltsan Expires March 5, 2010 [Page 8]
Internet-Draft Using OAuth for Recursive Delegation September 2009
who they would delegate permissions to. A client may not delegate
recursively to anyone else than permitted by the user. The resource
owner should only allow trustworthy clients to do the recursive
delegation. The resource owner should be able to track all the
transactions to the protected resource from the different the
clients/users. Resource owners should be able to complain about
clients that abuse this trust at the server.
5.2. Phishing Attack
Security considerations related to the phishing attack are described
in [draft-ietf-oauth-web-delegation].
6. IANA Considerations
This Internet Draft includes no request to IANA.
7. Acknowledgements
The authors are grateful to 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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[draft-ietf-oauth-authentication]
Hammer-Lahav, E., "The OAuth Protocol: Authentication",
draft-ietf-oauth-authentication-01.txt (work in progress),
July 2009.
[draft-ietf-oauth-web-delegation]
Hammer-Lahav, E., "The OAuth Protocol: Web Delegation",
draft-ietf-oauth-web-delegation-01.txt (work in progress),
July 2009.
Vrancken & Zeltsan Expires March 5, 2010 [Page 9]
Internet-Draft Using OAuth for Recursive Delegation September 2009
8.2. Informative References
[RFC2617] Franks, P., Hallam-Baker, J., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
Appendix A. Terminology
The following terms are used in this document as defined in [draft-
ietf-oauth-authentication]:
Client
An HTTP client (per [RFC2616]) capable of making OAuth-
authenticated requests per [draft-ietf-oauth-authentication].
Server
An HTTP server (per [RFC2616]) capable of accepting OAuth-
authenticated requests per [draft-ietf-oauth-authentication].
Protected Resource
An access-restricted resource (per [RFC2616]) which can be
obtained from the server using an OAuth-authenticated request per
[draft-ietf-oauth-authentication].
Resource Owner
An entity capable of accessing and controlling protected resources
by using credentials to authenticate with the server.
Token
An unique identifier issued by the server and used by the client
to associate authenticated requests with the resource owner whose
authorization is requested or has been obtained by the client.
Tokens have a matching shared-secret that is used by the client to
establish its ownership of the token, and its authority to
represent the resource owner.
The following terms are defined in this document:
first Client
A Client that has been authorized to access a Protected Resource
by the Resource Owner.
second Client
A Client that has been authorized to access a Protected Resource
by the First Client.
Vrancken & Zeltsan Expires March 5, 2010 [Page 10]
Internet-Draft Using OAuth for Recursive Delegation September 2009
Appendix B. Other examples
The Resource owner could delegate access and the right to delegate to
a content manager. The content manager could provide several third
party services, like a photo service. The content manager could
delegate access to the photo service on behalf of the user, allowing
the photo service to get the protected resource directly from the
server.
Authors' Addresses
Bart Vrancken
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp,
Belgium
Phone: +32 3 2409804
Email: Bart.bv.Vrancken@alcatel-lucent.be
Zachary Zeltsan
Alcatel-Lucent
600 Mountain Avenue
Murray Hill, New Jersy
USA
Phone: +1 908 582 2359
Email: zeltsan@alcatel-lucent.com
Vrancken & Zeltsan Expires March 5, 2010 [Page 11]