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

[Torsten Lodderstedt <[e-mail]>]

I'm refering to a siuation where a single authorization server manages 
access to multiple resource serveres and a client seeks authorization 
for some of this resource servers. I assume this would also happen in 
your scenario once the OP discovers that access to calendar and address 
book are protected by the same authorization server. How would you 
envision the authorization process (user consent) and token exchange 
between OP, authorization server and RP/client in such a situation?

regards,
Torsten.

> Are you referring to my OpenID v.Next NewSocialService scenario?
>
> What issues do you see doing this in v.Next rather than OAuth?
>
> Using OpenID allows the client/RP to only discover the user's OP, 
> which knows where the user's calendar / address book is.
>
> Having the OP as an intermediary allows it to interact with the user 
> to select which address book or calendar to provide in a particular 
> context cleanly solves the multiple service provider issue
>
> -- Dick
>
>
> On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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 <http://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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>