I hope to be writing-up a draft that will include text that discusses similarities.
In terms of operability, one possible approach is placing a KDC behind an OAuth AS, and making the OAuth RS a Kerberized service. All Krb messages would be encoded in GSSAPI token format (base64 encoded), as is done in other specs. This makes all the Krb messages opaque to OAuth. What I then need is some way to indicate in the access_token, refresh_token and client_secret that the contained data is Kerberos data. Would this work? /thomas/ > -----Original Message----- > From: Richer, Justin P. [mailto:jric...@mitre.org] > Sent: Wednesday, May 26, 2010 2:50 PM > To: Thomas Hardjono; Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] multiple access tokens from a single authorization > flow? > > 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
