Hi Torsten,
I think this problem can also be solved with down-scoping support on
the refresh call (or a separate flow as Dick suggested).
The client would get back a single access token and corresponding
refresh token. It then can use the "refresh" call with an optional
scope to get a narrow access token. The original access token (the one
that came along the refresh token) would be discarded.
I realized that with down-scoping it is up to the client to do the
right thing, but I don't think that multiple access tokens can really
solve the issue. In your example, what if there are three types of
APIs:
- requiring only "calendar" scope
- requiring only "contacts" scope
- requiring both "calendar" and "contacts" scopes
How would the authorization server know how many access tokens to
issue based only on requested scopes? The client knows what narrow
access tokens it needs because it knows what APIs it intends to use.
Marius
On Mon, May 24, 2010 at 9: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
