Re: [OAUTH-WG] multiple access tokens from a single authorization flow?

["Keenan, Bill" <[e-mail]>]

Thanks Torsten for more of your good thinking and write-up...

At Intuit, using 1.0a, we did an experiment with one of our mobile apps using multiple tokens. The programming model of having the client maintain a mapping of token to ROA endpoint, so they used the correct token turned out to be a headache. We bailed on this, and moved to a single token, and used a mechanism server-side to manage the principle of least-privilege. As all the resources the mobile app needed were hosted by Intuit, we had this option. As we get to apps doing mashups of entities from multiple data providers, apps will need to manage multiple tokens.

At Intuit, we have been wrestling with scope for several months. With 100's going to 1000's of entities, which each have 4 - 15 verbs, expressing the set of endpoints, which a token should allow access to is complicated. I don't see an opportunity to normalize the complexity, so we are all interoperable on the cardinality of tokens to the protected resources an application needs from a specific provider. I'll push for single token in my world; others want multiple tokens (maybe).

Experience pushes me towards providing the application developer a way to say everything they need, and getting a single token to use in accessing those endpoints. Much of our access control is built around an RBAC, so issuing a token with one or more roles would provide access to all the endpoints available to the role(s). The developer learns, from SDK documentation, the roles an API is available to. In our case, we don't want developers understanding how Intuit's datacenters are organized, so we would not want them getting multiple tokens because they thought they were crossing some boundary of our internal deployment.

Right now, multiple tokens does not help me. I am sure it could help some. My caution to those going down the multi-token path is exposing more of your deployment than needed by having developers get tokens for specific areas.

BillK

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Torsten Lodderstedt
Sent: Monday, May 24, 2010 9:18 AM
To: OAuth WG ([e-mail])
Subject: [OAUTH-WG] multiple access tokens from a single authorization flow?

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth