Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow

[Eran Hammer-Lahav <[e-mail]>]

I'll let you know when I see the I-D :-)

EHL

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[e-mail]]
> Sent: Friday, June 11, 2010 12:51 PM
> To: Eran Hammer-Lahav
> Cc: David Recordon; OAuth WG ([e-mail])
> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single
> authorization flow
> 
> 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of David Recordon
> >> Sent: Thursday, June 10, 2010 8:54 AM
> >> To: Torsten Lodderstedt
> >> Cc: OAuth WG ([e-mail])
> >> 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
> >> <[e-mail]>  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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>