Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

From: "Manger, James H" <[email-masked]>
Date: Sat, 2 Jun 2012 00:33:02 +1000

Adam,

You are describing OpenID Connect.

--
James Manger

----- Reply message -----
From: "Lewis Adam-CAL022" <[email-masked]>
Date: Sat, Jun 2, 2012 12:00 am
Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited)
To: "[email-masked]" <[email-masked]>

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 1 Jun 2012 15:00:24 +0000

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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 1 Jun 2012 16:19:03 +0000

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:[email-masked]] 
Sent: Friday, June 01, 2012 10:00 AM
To: Manger, James H
Cc: Lewis Adam-CAL022; [email-masked]
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

 -- Justin

On Jun 1, 2012, at 10:33 AM, Manger, James H wrote:

> 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)
> 
> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 1 Jun 2012 16:00:23 -0400

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:
>> From: "Lewis Adam-CAL022"<[email-masked]>
>> To: "[email-masked]"<[email-masked]>
>>
>> Hi all,
>>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 1 Jun 2012 20:17:06 +0000

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:[email-masked]] 
Sent: Friday, June 01, 2012 3:00 PM
To: Lewis Adam-CAL022
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

So in concrete terms:

  -- Justin

---

From: George Fletcher <[email-masked]>
Date: Fri, 01 Jun 2012 16:42:14 -0400

If you are using the "userinfo endpoint" concept to verify the 
unstructured token with the appropriate AS, then all you really need 
from the unstructured token is which AS to send it to. If your problem 
space is constrained so that this is straight forward, then there isn't 
a significant reason to use a structured token over an unstructured one. 
Though I could probably argue, that if you can determine the originating 
AS from the "unstructured" token then it's really "structured"; just not 
using JWT:)

Thanks,
George

---

From: Justin Richer <[email-masked]>
Date: Fri, 1 Jun 2012 16:45:05 -0400

Right, if you've got a fully signed JWT (using JWS) then you don't need 
much in introspection because you *can* pack everything in the token. 
But introspection gives you the option to put some bits in the token and 
leave some other bits as a callable API, which is nice.

If you don't use a JWT, I would at least suggest using a 
slightly-structured token so that your RS can key which AS the token 
came from. Otherwise it's going to have to check all of them, which is a 
huge waste of bandwidth and time. (and very leaky security!!)

We've got a JWT-spewing implementation built on top of Spring Security 
OAuth in our OpenID Connect server, if you're up on Java and Spring and 
Spring Security (like a lot of our enterprise is) then it might be up 
your alley.

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server

This adds a set of token services to the existing Spring Security OAuth 
with some different capabilities, and one of these is a full Java JWT 
library.

  -- Justin

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Fri, 1 Jun 2012 20:46:03 +0000

Hi George,

I have other means to identify the domain/AS which generated the unstructured token ... so this is not an issue.

But I am still interested in JWT.  My question (to all on this list) is still, which OAuth AS implementations out there will actually give me a structured JWT access-token, in response to an Access Token request?  I realize that Connect may be looking to make more ubiquitous, but who does it today?

Tx!!
adam

From: George Fletcher [mailto:[email-masked]]
Sent: Friday, June 01, 2012 3:42 PM
To: Lewis Adam-CAL022
Cc: Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

If you are using the "userinfo endpoint" concept to verify the unstructured token with the appropriate AS, then all you really need from the unstructured token is which AS to send it to. If your problem space is constrained so that this is straight forward, then there isn't a significant reason to use a structured token over an unstructured one. Though I could probably argue, that if you can determine the originating AS from the "unstructured" token then it's really "structured"; just not using JWT:)

Thanks,
George

Hi Justin,

Tx!

adam

-----Original Message-----

To: Lewis Adam-CAL022

Cc: Manger, James H; [email-masked]<mailto:[email-masked]>

So in concrete terms:

  -- Justin

Tx!

adam

-----Original Message-----

To: Manger, James H

Cc: Lewis Adam-CAL022; [email-masked]<mailto:[email-masked]>

  -- Justin

Adam,

--

James Manger

----- Reply message -----

From: "Lewis Adam-CAL022"<[email-masked]><mailto:[email-masked]>

To: "[email-masked]"<mailto:[email-masked]><[email-masked]><mailto:[email-masked]>

Hi all,

            RS (domain-1)

Tx!

adam

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>