Hi Justin, Yes ... this is making me feel a lot better about things. So just a few more points of clarification:
1. if the OAuth access-token is a JWT, then it seems there is nothing for me to introspect ... because all the info is in the JWT and the RS can validate the signature itself. 2. what OAuth AS implementations today actually give me a structure JWT access-token? Most that I am aware of give me an unstructured token. 3. even if I could get a JWT (which I would definitely be interested in exploring) the unstructured token still gives my major bandwidth advantage (again, because of my edge cases). Tx! adam -----Original Message----- From: Justin Richer [mailto:jric...@mitre.org] Sent: Friday, June 01, 2012 3:00 PM To: Lewis Adam-CAL022 Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) First, I have to give proper credit to my colleague Amanda Anganes for making those flow diagrams (which I agree are pretty awesome -- when coding I refer to them as often as the spec text itself, personally). Yes, you have it right, in this case the RS is the client of the identity API from the AS, which looking back at your original question isn't quite what you were asking, so I apologize for the confusion there. Just so I have this straight: You have a client, C, making an OAuth protected call to service RS using a token that's been generated by one of a set of trusted authorization servers, AS1-AS12. So RS needs to figure out: 1) Is the token any good? 2) Is the token issued by someone I know? 3) What's the user information tied to the token? (name and stuff) If that's the case, there are a few ways to handle this, but one of the simplest is to make use of the bearer token principle and chain the service calls around a bit. Especially if your AS's all use a structured token format, like JWT, that can point to the issuer of the token (and therefore which AS spit it out in the first place). So in concrete terms: Client C calls AS1 and gets access token AT. AT is a JWT that has in its claims section {iss: AS1}, among others. C passes AT to RS to make its call. RS can inspect the JWT and discover the token was sent from AS1 (by the issuer field). RS knows that AS1 is in its list of trusted AS's. RS validates the signature on AT against the key from AS1 (which can be done using JWK). Now that the token is good, the RS can start to fulfill the client's request. The RS could also call what's being termed an "introspection endpoint" at AS1 to help it figure out what the token is good for (scopes, permissions, timeouts, etc) in fulfilling the client's request. But say RS needs user information like a name and email address and all that. Well, if the AS's are all doing OpenID Connect, which would still give you a valid access token, then the AS's will all *also* have a User Info Endpoint defined. The RS can send the AT to the UserInfo Endpoint to get the user's information from it in a simple JSON schema. You can alternatively use SCIM or PoCo formatted endpoints to accomplish much of the same stuff, all protected over OAuth. There are some more complicated methods, with the RS trading in the AT for its own subscoped AT for instance, but this is a basic and fairly functional usage scenario. Do you think this covers what you'd want to do with it? It's still about 80% vanilla OAuth2. -- Justin On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: > Maybe I'm getting confused over the terminology. Connect speaks of a client > talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as the > client in this case? > > I'm actually looking at your famous PDF diagrams Justin, and it looks like > the client is in all cases the same client. E.g. the client that asks for > the access token is the same client performs the UserInfo request or CheckID > request. In my mind, I want the client to get the access-token and present > it to the RS, and then I want the RS to perform the UserInfo request or > CheckID request. > > So if you're telling me that the RS is acting as the client, and the RS can > perform the UserInfo request or CheckID request, then I get it. But it > wasn't obvious from the spec. > > > Tx! > adam > > > > > -----Original Message----- > From: Richer, Justin P. [mailto:jric...@mitre.org] > Sent: Friday, June 01, 2012 10:00 AM > To: Manger, James H > Cc: Lewis Adam-CAL022; oauth@ietf.org > Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > > More specifically, OpenID Connect with the addition of reusing the > access_token provided by the AS to get at other API services. This capability > is explicitly encouraged in Connect since it directly re-uses the OAuth2 > infrastructure and tokens to do the identity protocol. > > -- Justin > > On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > >> Adam, >> >> You are describing OpenID Connect. >> >> -- >> James Manger >> >> ----- Reply message ----- >> From: "Lewis Adam-CAL022"<adam.le...@motorolasolutions.com> >> Date: Sat, Jun 2, 2012 12:00 am >> Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >> To: "oauth@ietf.org"<oauth@ietf.org> >> >> Hi all, >> >> I've asked about the lack of standardization of the AS-RS interface in the >> past, but I have a new twist on my question. What is the viability of >> performing user "authentication" using OAuth with an RS in domain-1, and a >> whole bunch of AS's in different domains (assuming that the RS and AS is of >> the same implementation)? >> >> RS (domain-1) >> >> AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >> >> Let me explain a bit further. I have a RS in domain-1 which exposes an API, >> which is accessed by a native client, with users from (for example) 12 >> different domains. (Note: both the RS and native clients are of the same >> vendor implementation). Each of the 12 user domains has an AS, of the same >> implementation as the RS in domain-1. I'm thinking that native client users >> from domain X should be able to authenticate to the AS in their home domain >> using some primary authentication means, obtain an unstructured >> access-token, and present that access-token to the RS in domain-1. Because >> they are all of the same implementation, the RS in domain-1 should be able >> to make a RESTful API call to the AS in domain X to obtain a JSON structure, >> containing among other things, the user's name, and possibly other >> attributes. Hence secondary authentication has been realized. >> >> This seems to work, but is this within the spirit of OAuth, or have I gone >> off into LaLa land? We have looked at using the SAML bearer assertion >> profile for OAuth, but we do a lot over wireless links, many of which are >> bandwidth anemic, and the overhead of obtaining the SAML assertion and >> sending it are making me a bit squeamish. OAuth is attractive because of >> its light weight-ness. Is the usage I'm proposing of OAuth (above) >> something that would be within the overall spirit of the OAuth framework? >> >> Tx! >> adam >> _______________________________________________ >> 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
