Hi,
thanks for your advice. I described the new parameter in my proposal.
What additional text/information would you expect in an I-D?
regards,
Torsten.
Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav:
I strongly believe that it should be first presented as an I-D. This is true in
general for most proposed changes of this size. It is hard to tell how big of
an impact a change like this will have without some actual text. Once proposed,
the WG can decide if this is of interest as a WG item. If it is, we discuss the
technical details. Then, we can have a chat about editorial work and how to
best fit it within the OAuth specifications framework.
Hope this helps.
EHL
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of David Recordon
Sent: Thursday, June 10, 2010 8:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single
authorization flow
I strongly believe that it should be an extension. Even optional response
parameters increase the complexity for client developers and this in
particular affects the data model used to store access tokens.
--David
On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
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
_______________________________________________
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
