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]