no one in the WG having an opinion on this topic?
Am 09.06.2010 12:19, schrieb Torsten Lodderstedt:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
