Not really, because it’s not refreshing access. It’s getting access in the context of a separate access token, which wasn’t issued to it. The mechanism is similar to a refresh token but that’s it.
— Justin > On Mar 26, 2015, at 3:13 PM, Bill Mills <wmills_92...@yahoo.com> wrote: > > By definition an access token is becoming a form of refresh token. The > "because my implementation didn't do it that way" isn't convincing me. > > > > On Thursday, March 26, 2015 12:44 PM, Justin Richer <jric...@mit.edu> wrote: > > > Because many implementations (including mine which does support my old token > chaining draft) treat access tokens and refresh tokens separately in terms of > data store and structure. Additionally, the refresh token is tied to the > client and presented by the client. But in this case it's someone downstream, > an RS, presenting the token. So unlike a refresh token being presented by the > one it was issued to, this token is being presented by someone it was > presented to. > > The feeling is close, but not quite the same in either development or > assumptions. > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Bill Mills <wmills_92...@yahoo.com> > Date: 03/26/2015 2:24 PM (GMT-06:00) > To: Justin Richer <jric...@mit.edu>, "<oauth@ietf.org>" <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Token Chaining Use Case > > So why can't the access tokne simply be re-used as a refresh token? Why > would it need a new grant type at all? > > > > > On Thursday, March 26, 2015 11:31 AM, Justin Richer <jric...@mit.edu> wrote: > > > As requested after last night’s informal meeting, here is the token chaining > use case that I want to see represented in the token swap draft. > > > [ Client ] -> [ A ] -> [ B ] -> [ C ] > > An OAuth client gets an access token AT1, just like it always would, with > scopes [A, B, C] in order to call service A, which requires all three scopes. > Service A (an RS) accepts this token since it has its scope, and then needs > to call service B in turn, which requires scopes [B, C]. It could just > re-send the token it got in, AT1, but that would give the downstream RS the > ability to call services with scope [ A ] and it should not be allowed to do > that. To limit exposure, service A calls a token swap at the AS to create AT2 > with scopes [ B, C ], effectively acting as an OAuth client requesting a > downscoped token based on AT1. Service A then acts as an OAuth client to call > service B, now acting as an RS to service A’s client, and can fulfill the > request. And it’s turtles all the way down: Service B can also call service > C, and now B acts as a client, requesting AT3 with scope [ C ] based on AT2, > and sending AT3 to service C. This prevents C from being able to call B or A, > both of which would have been available if AT1 had been passed around. Note > that service A or the Client can also request a downscoped token with [ C ] > to call service C directly as well, and C doesn’t have to care how it got > there. > > > In other words, it lets the client software be very, very dumb. It doesn’t > have to do any special processing, doesn’t have to know what’s in the token, > it just follows the recipe of “I got a token, I get another token based on > this to call someone else”. It’s also analogous to the refresh token flow, > but with access tokens going in and out. I’ve deployed this setup several > times in different service deployments. Even though there is a performance > hit in the additional round trips (as Phil brought up in another thread), in > these cases the desire to have the tokens hold least privilege access rights > (smallest set of scopes per service) outweighed any performance hit (which > was shown to be rather small in practice). > > What I want is for the token swap draft to define or use a mechanism that > allows us to do this. I think we can do that pretty easily by adjusting the > token swap syntax and language, and explicitly calling out the semantic > processing portion (the current core of the document) for what it is: a way > for a token issuer to communicate to a token service specific actions. At a > high level, the spec would be something like: > > > > 1. How to swap a token at an AS > 1. Send a request to the token endpoint with a new grant type, and a token > (of any type/format/flavor) on the way in > 2. Get back a new token in a token response > 2. Communicating act as / on behalf of semantics via a JWT assertion > 1. How to create (as an AS/RS/client/other issuer) a JWT with act-as > semantics > 2. What to do (as an AS/RS) with a JWT with act-as semantics > 3. How to create a JWT with on-behalf-of semeantics > 4. What to do with a JWT with on-behalf-of-semantics > 5. How to possibly represent these semantics with something other than a JWT > > > > Section 2 uses the syntax from section 1. Other applications, like the one I > laid out above, can use the syntax from section 1 as well. This works for > structured, unstructured, self-generated, cross-domain, within-domain, and > other tokens. > > > — Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
