Hi Brian, Right ... so I suppose looking at that diagram without the background text would have been a bit odd :)
In my use case I have an OAuth client that is going to request many access tokens, for many different resource servers. All of these resources servers will be protected by the same AS. (I think this is similar to Google's OAuth in that they have many APIs served by many resource servers, which all use the same OAuth authorization endpoint). My client *could* ask for an access token with enough scopes to cover all the resource server APIs (again, similar for example to the Google OAuth playground), but this does not meet the assurance levels of my use cases. RS1 has no business possessing an AT that could be used to access protected resources at AS2 and AS2 has no business having the same AT that would allow it access protected resource at AS3, and so on. I have toyed around with the idea making an initial OAuth request with an uber-scope, and then using the refresh token to obtain the down-scoped access tokens and sending those down-scoped access tokens to the RS's. But the problem I'm running into with this is that my client may not know a priori all the RS's it's going to need access tokens for. So the JWT assertion flow began to look nearly perfect to me. If you look at the diagram again, it should look (very) familiar to something we all grew up with: Kerberos! The first exchange is to obtain the TGT, and the subsequent exchange uses the TGT to get a service ticket. So using this analogy: Kerberos TGT = JWT assertion Kerberos TGS = access token I can use the JWT assertion obtained in step 1 to request access tokens on the fly for resource servers at the client needs to access them, just as the TGT is used to obtain the TGS on-demand. I think this is totally within the realm of reason. We will likely prototype this idea very early next year (Jan/Feb). -adam From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Friday, December 14, 2012 3:14 PM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using structured access_token as grant type in assertion flow Maybe I'm missing the bigger picture but, if your going back to the same AS like the diagram shows, why not just request the xyz scope in the initial request and cut out the middle steps? More generally I can say I've thought about these kinds of token exchange cases and they should be possible in theory. In practice I expect getting everything to work and validate correctly with respect to scopes and audience values might be a little tricky. On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 <adam.le...@motorolasolutions.com<mailto:adam.le...@motorolasolutions.com>> wrote: Hi, I continue to have an interest in the OAuth assertion profiles for my use cases. I'm wondering if the idea of performing a first OAuth dance which returns to the client a structured JWT access token (with scope=AS for example) could then be used as the JWT in an assertion grant type? So something like this (I show the RO credential flow since it is the simplest to draw, but same idea for the code flow): Client AS | | |---------------->| (authorization request scope=AS, grant_type=RO password credentials) | | |<----------------| (token response with access_token scoped to AS) | | |---------------->| (authorization request, scope=xyz, grant_type=JWT assertion as obtained from previous step) | | |<----------------| (token response with access token scoped to xyz) I suppose there is nothing in theory which should prevent this, but I am wondering if anybody else has thought of such a usage. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
