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
