Hi all,
I would like to see support in OAuth2 for the authorization of arbitrary
scopes in a single authorization flow for all kinds of deployments. In
some deployments this may require to issue multiple access tokens at once.
Therefore, I would like to propose the following addition to section
2.3.2.1. (Access Token Response):
Add an optional parameter "additional_access_tokens".
additional_access_tokens
OPTIONAL. Array of access tokens issued by the authorization
server along with respective expiration and scope.
Used
if the authorization server decides to issue more than
one access token. The scopes of the different
tokens may
not overlap.
Example:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8",
scope:"https://imap.example.com";,
additional_access_tokens:[
{
"access_token":"SlAV32hkKG2",
"expires_in":3600,
scope:"https://sip.example.com";
},
{
"access_token":"SlAV32hkKG3",
"expires_in":3600,
scope:"https://contacts.example.com/read";
},
{
"access_token":"SlAV32hkKG4",
"expires_in":3600,
scope:"https://webdav.example.com/read";
}
]
}
--- Some motivation ---
I think we will see more and more clients integrating different end-user
services (like mashups). Based on the current draft, some OAuth
authorization servers may not be able to support such clients with an
acceptable user experiences.
Suppose a communication client integrating the following services:
- e-Mail via IMAP
- Voice over IP using the SIP protocol
- Contacts via SyncML over HTTP
- Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV
For a particular end-user, the client may discover that all of the
end-user's services rely on the same OAuth2-based authorization server
because they are provided by the same organization (e.g. an isp or a
telco). The services are distinguished at the authorization server by
different scopes (probably including permissions as well), e.g. :
imap - https://imap.example.com
sip - https://sip.example.com
contacts - https://contacts.example.com/read
webstorage - https://contacts.example.com/read
Some providers may want to issue different service-specific tokens in
such a setup (Deutsche Telekom does it already), for the following reasons:
1) Security
a) minimize impact of token abuse - tokens may leak in many ways, e.g.
through log files, proxies or HTTP referer. If a provider just uses a
single token for all services, the impact of token leakage is much
higher. For example, if a token gets exposed by the _contacts_ service
via HTTP referer, an adversary may place long-distance calls using that
token on the _VoIP_ service at the expense of the end-user. This threat
holds for all kinds of tokens (handles and self-contained tokens).
b) use a shared secret between authz server and a single service only
- a major critism from the operational security perspective to OAuth
1.0a was the need to spread client secrets to resource servers. Using
the same shared secret to sign/encrypt tokens for different services is
a comparable problem. This aspect is relevant for self-contained tokens,
only.
2) Privacy - the provider wants to restrict access of services to
personal data to the data a particular service is allowed and authorized
to see. This is good style (IMHO), it might also be required by law
(e.g. German Federal Data Protection Act). This aspect is relevant for
self-contained tokens, only.
3) Bandwith efficiency - putting only the data required by the services
into the token saves bandwith. This aspect is relevant for
self-contained tokens, only.
In my opinion, most of these aspects are just a consequence of the
decoupling of authorization server and resource server(s) in OAuth2. If
a single authorization server is responsible for several resource
servers, it has to ensure privacy protection and prevention of token
abuse for all of its services. This should also include some separation
between services, no matter if one uses self-contained tokens or handles.
Without the change I proposed, the authorization server in the example
scenario would need to force the client to perform _four_ subsequent
authorization flows in order to obtain all required tokens. Moreover,
the client would need to manage four refresh tokens.
I would kindly ask you to support my proposal. In my opinion, it
significantly improves the applicability of OAuth2 while the change to
the current draft is minimal. Moreover, deployments w/o the need to
issue multiple tokens are not affected at all.
Any thoughts?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
