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
On 06/01/2012 04:17 PM, Lewis Adam-CAL022 wrote:
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
