>From what I understand, there is no inherent similarity between the two. You
>*can* wire up your AS and PR to do some verification of that caliber, but it's
>not required by the OAuth spec. For cases when the AS and PR are collapsed
>into a single system (which is a large percentage of use cases outside of the
>Big Internet Companies, from what I gather), then all you need to do to prove
>that the access and refresh token are related is by a lookup to a local
>database table.
-- justin
________________________________________
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Thomas
Hardjono [hardj...@mit.edu]
Sent: Wednesday, May 26, 2010 2:27 PM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow?
I do realize several people on this list should see the parallel :) Several
folks at the last IETF OAuth meeting also brought-up the similarities.
One of the aspect unclear to me with OAuth draft-05 is the cryptographic
relationship between the Refresh Token ("8xLOxBtZp8") and the Calendar token
("SlAV32hkKG") & Contacts token ("SlAV32hkAB"). That is, how can a verifying
third party be satisfied that the access came from the same Client/Session.
/thomas/
__________________________________________
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Wednesday, May 26, 2010 2:18 PM
> To: Thomas Hardjono
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization
> flow?
>
> I also realized the parallels of refresh tokens and TGTs. That's why I said
>
> "Are these refresh tokens still long-living or as short-living as a
> Kerberos TGT?"
>
> when discussing Marius's proposal. In my opinion, the main difference
> between TGT and refresh token is the live-time. Refresh tokens may have
> a unlimited validity whereas TGTs as far as I know live for at least 24h
> (incl. re-newal).
>
> We can use refresh tokens the same way as TGTs but than every flow must
> return a refresh token and, in my opinion, aquisition of access tokens
> (or call it services tickets :-)) should be a second step using the
> refresh request.
>
> At request level, this would look as follows
>
> Obtaining token flow result
>
> HTTP/1.1 200 OK
> Content-Type: application/json
> Cache-Control: no-store
>
> {
> "refresh_token":"8xLOxBtZp8"
> }
>
> Acquiring token for scope "calendar"
>
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
>
> type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&
> refresh_token=8xLOxBtZp8&scope=calendar
>
> HTTP/1.1 200 OK
> Content-Type: application/json
> Cache-Control: no-store
>
> {
> "access_token":"SlAV32hkKG",
> "expires_in":3600
> }
>
> Acquiring token for scope "contacts"
>
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
>
> type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&
> refresh_token=8xLOxBtZp8&scope=contacts
>
> HTTP/1.1 200 OK
> Content-Type: application/json
> Cache-Control: no-store
>
> {
> "access_token":"SlAV32hkAB",
> "expires_in":3600
> }
>
>
> regards,
> Torsten.
>
> > 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
