[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.