Hi Torsten, Looking at your example below (with the user having to login/consent several times), it seems what is needed is multiple short-term (narrower) tokens that is provably derived from one single (parent) longer-life token. So the human user would need to consent only once to the parent longer-life token, and the client would fetch the multiple shorter-life tokens automatically. The keyword here is "provably" (which may be read as "cryptographically provable").
BTW. Apologies for the history lesson, but this was the same problem with Kerberos when it was first deployed at MIT project Athena in the late 1980s. The solution was to create a separate Ticket-Granting-Ticket (TGT) with the user being prompted for a password only once. Then the Kerberos client would obtain Service Tickets (to access resources) using the TGT. /thomas/ > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Torsten Lodderstedt > Sent: Tuesday, May 25, 2010 4:21 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization > flow? > > ..... > With the current draft, the client has to send the user through the > authz process n-times (n = number of services). This would look this: > > user accesses client > REDIRECT AS > Login at AS > User Consent service 1 > REDIRECT back > get access token for service 1 > REDIRECT AS > SSO at AS > User Consent service 2 > REDIRECT back > get access token for service 2 > REDIRECT AS > SSO at AS > User Consent service 3 > REDIRECT back > get access token for service 3 > > What a user experience is that? And imagine such a use case for the > device flow :-( > > Do we have other options to perform this process more user-friendly? > > First of all, how does the client request authorization for different > services? As far as I see, the scope parameter is the only way to pass > such information to the authorization server. So instead of mererly > denoting permissions, we can use scopes as kind of service id + permissions. > > Which options do we have for returning tokens to the client? > > As proposed by Marius, the authorization server could issue a refresh > token and the client could use the refresh request in combination with > the downscoping feature in order to acquire access tokens. > Consequences? > In the setup illustrated above, the authorization server cannot create > any access token (or an arbitrary one), it can only return a refresh > token. This would mean to make the access token response parameter > optional. Here I'm colliding with my mental picture of refresh tokens as > long-living and storable tokens. Are these refresh tokens still > long-living or as short-living as a Kerberos TGT? If they are still > long-living, what about the use cases where we don't want to return > refresh tokens? As far as I remember, user agent and username/password > flow were candidates. How shall we handle them? > > Coming back to my original proposal: The authorization server could also > issue multiple access tokens and (optionally) a refresh token - > preserving the refresh token semantics. > > Justin pointed out that my original proposal added complexity to the > simplest use case even if the authorization server does not issue > multiple tokens. I understand your objection and would like to suggest a > modified response structure. Instead of putting all access token into an > array, the authz server could also use the structure as defined in the > current draft and use another list of "additional_access_tokens", if > more than one token has been created. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkAB", > "scopes":"calendar", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > additional_access_tokens = [{ "token":"SlAV32hkKG", > "scopes":["calendar"], "expires_in":3600}, ...] > } > > So in the simplest case, the response would look the same as before. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkAB", > "scopes":"calendar", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8" > } > > 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
