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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, May 24, 2010 9:18 AM To: OAuth WG (oauth@ietf.org) 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
