Couldn't be used a specific type of refresh_token ? Instead of using grant_type=refresh_token use a grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as an extension to refresh token flow ?
Regards. Pedro Igor ----- Original Message ----- > From: "Bill Mills" <wmills_92...@yahoo.com> > To: "Donald F. Coffin" <donald.cof...@reminetworks.com>, "Phil Hunt" > <phil.h...@oracle.com> > Cc: oauth@ietf.org > Sent: Thursday, March 26, 2015 6:13:05 PM > Subject: Re: [OAUTH-WG] Token Chaining Use Case > > The RS calling back to the AS won't be confused, the token it gets would be > it's refresh token. I don't see any reason why the AS can't be smart enough > to know that a token that looks like an access token it issued is usable as > a refresh token for limited purposes or downscoping. > > > > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin > <donald.cof...@reminetworks.com> wrote: > > > -1 > Although Justin’s point might be a bit pre-mature as far as a standards > discussion, the more critical reason IMHO is calling the AS’s /Token > endpoint with a grant_type of “refresh_token” but providing an issued AT > rather than an issued refresh_token (RT) will definitely create a backwards > compatibility issue for many implementations. > Best regards, > Don > Donald F. Coffin > Founder/CTO > REMI Networks > 2335 Dunwoody Crossing Suite E > Dunwoody, GA 30338-8221 > Phone: (949) 636-8571 > Email: donald.cof...@reminetworks.com > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Thursday, March 26, 2015 4:22 PM > To: Bill Mills > Cc: <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Token Chaining Use Case > +1. We all have to change production code when non final specs evolve. > I particularly don't see this as a valid argument at the start of a standards > discussion. > > Phil > > On Mar 26, 2015, at 15:13, 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 > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
