[OAUTH-WG] multiple access tokens from a single authorization flow?
Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 24 May 2010 16:18 UTC
Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34AE13A69F0 for <oauth@core3.amsl.com>; Mon, 24 May 2010 09:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.321
X-Spam-Level:
X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeSISojYqdrB for <oauth@core3.amsl.com>; Mon, 24 May 2010 09:18:01 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id DF26A3A6A06 for <oauth@ietf.org>; Mon, 24 May 2010 09:17:57 -0700 (PDT)
Received: from p4fff13ed.dip.t-dialin.net ([79.255.19.237] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OGaLc-0007vp-Vq for oauth@ietf.org; Mon, 24 May 2010 18:17:49 +0200
Message-ID: <4BFAA6AB.8040809@lodderstedt.net>
Date: Mon, 24 May 2010 18:17:47 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Subject: [OAUTH-WG] multiple access tokens from a single authorization flow?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2010 16:18:02 -0000
How many access tokens can be the result of a single OAuth authorization flow? A recent discussion about OpenID Connect on the OpenId mailing list raised that question and I would like to initiate a discussion on this list. Currently, every flow (and the refresh token request) results in a single access token and (optionally) a single refresh token. I think a single access token might not be enough when it comes to multiple scopes. Let's assume a client wants to access the calendar and contact list of an end-user. Since access to the corresponding resource servers is managed by the same authorization server, the resources are distinguished by different scopes, say "calendar" and "contacts". The client sends a request GET /authorize?type=web_server&client_id=s6BhdRkqt3&redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=calendar%20contacts HTTP/1.1 Host: oauth.example.com and after the authorization flow has been conducted sucessfully, the client's access token request would be answered as follows. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600, "refresh_token":"8xLOxBtZp8" } So the token "SlAV32hkKG" must be good for two different protected resources, "calendar" and "contacts". I think this works if: 1) the token is a handle that can be swoped for user identity and authorization data during service request or 2) it is a self-contained token AND both resources are provided by the same resource server. But what if the authorization server issues self-contained tokens and the resources are hosted on different, independent resource servers? Let's assume the authorization server issues self-contained, signed, and encrypted bearer tokens. Signature and encryption are based on shared secrets between authorization server and resource server. In such a scenario, operational security requires to issue different tokens with different signature values and to encrypt those tokens with different keys. Moreover, the resource servers might need different user attributes and permissions, so even the tokens payload might differ. I believe this scenario will become even more important with the advent of OpenID Connect. With OpenID connect, every client asking for an end-user's OpenID (+user data) and, additionally, authorization for another resource will need at least two tokens under the assumptions given above. In order to support such scenarios, I would propose to return an array of access tokens from every authorization flow and the refresh request. An authorization server should know which resources and scopes are handled by what resource servers and indicate this relation in the access tokens response structure. This structure could be as follows. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_tokens":[ { "token":"SlAV32hkKG", "scopes":["calendar"], "expires_in":3600}, { "token":"SlAV32hk34", "scopes":["contacts"], "expires_in":7200},], "refresh_token":"8xLOxBtZp8" } The scopes a particular access token is good for are indicated, so a client library is able to choose the right tokens for services requests. Alternatively it might suffice (or be better?) to indicate the sites a token is valid for (proposal of James Manger). It think there is no need for multiple refresh tokens because these tokens are handled by the authorization server only. In case all resources are handled by the same resource server, the result would look like HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_tokens":[{ "token":"SlAV32hkKG", "expires_in":3600},], "refresh_token":"8xLOxBtZp8" } Thoughts? regards, Torsten.
- [OAUTH-WG] multiple access tokens from a single a… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Keenan, Bill
- Re: [OAUTH-WG] multiple access tokens from a sing… Marius Scurtescu
- Re: [OAUTH-WG] multiple access tokens from a sing… Manger, James H
- Re: [OAUTH-WG] multiple access tokens from a sing… Marius Scurtescu
- Re: [OAUTH-WG] multiple access tokens from a sing… Manger, James H
- Re: [OAUTH-WG] multiple access tokens from a sing… Richer, Justin P.
- Re: [OAUTH-WG] multiple access tokens from a sing… Manger, James H
- Re: [OAUTH-WG] multiple access tokens from a sing… Luke Shepard
- Re: [OAUTH-WG] multiple access tokens from a sing… Marius Scurtescu
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Marius Scurtescu
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Marius Scurtescu
- Re: [OAUTH-WG] multiple access tokens from a sing… Thomas Hardjono
- [OAUTH-WG] Proposal: Redesigning the Refresh Toke… Thomas Hardjono
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Thomas Hardjono
- Re: [OAUTH-WG] multiple access tokens from a sing… Richer, Justin P.
- Re: [OAUTH-WG] multiple access tokens from a sing… Thomas Hardjono
- Re: [OAUTH-WG] multiple access tokens from a sing… Dick Hardt
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Lukas Rosenstock
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- Re: [OAUTH-WG] multiple access tokens from a sing… Justin Richer
- Re: [OAUTH-WG] multiple access tokens from a sing… Torsten Lodderstedt
- [OAUTH-WG] proposal: multiple access tokens from … Torsten Lodderstedt
- Re: [OAUTH-WG] proposal: multiple access tokens f… Torsten Lodderstedt
- Re: [OAUTH-WG] proposal: multiple access tokens f… David Recordon
- Re: [OAUTH-WG] proposal: multiple access tokens f… Igor Faynberg
- Re: [OAUTH-WG] proposal: multiple access tokens f… Eran Hammer-Lahav
- Re: [OAUTH-WG] proposal: multiple access tokens f… Torsten Lodderstedt
- Re: [OAUTH-WG] proposal: multiple access tokens f… Eran Hammer-Lahav
- Re: [OAUTH-WG] proposal: multiple access tokens f… Breno
- Re: [OAUTH-WG] proposal: multiple access tokens f… Eran Hammer-Lahav
- Re: [OAUTH-WG] proposal: multiple access tokens f… Justin Richer
- Re: [OAUTH-WG] proposal: multiple access tokens f… Breno
- Re: [OAUTH-WG] proposal: multiple access tokens f… Manger, James H
- Re: [OAUTH-WG] proposal: multiple access tokens f… Eran Hammer-Lahav
- Re: [OAUTH-WG] proposal: multiple access tokens f… Torsten Lodderstedt
- [OAUTH-WG] I-D: multiple access tokens Torsten Lodderstedt