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