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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
