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

Reply via email to