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 <
tors...@lodderstedt.net> 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
>
> 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
