What if A calls be with it’s own authorization token (server token ST1) and passes AT1 in another header e.g. on-behalf-of.
You save a call and can still check the scope downstream. Further, service B and C can each check whether ST1 and ST2 had the right to wield AT1 even when AT1’s POP proof is a proof of the external client. The only reason I can think to call the AS is if there is some dynamic condition that might cause an AS to reject the swap. If AT1 is valid, I can’t think of another reason why the answer isn’t already YES for all calls. If its no, its likely a permanent configuration problem not a dynamic decision. In other words, B always expects A to call it on behalf of some one. Likewise, C is always expecting B. Phil @independentid www.independentid.com phil.h...@oracle.com > On Mar 26, 2015, at 1:31 PM, 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
