[Openid-specs-ab] OpenID Connect + OAuth to cross domains
jricher at mitre.org
Mon Sep 10 14:00:48 UTC 2012
On 09/10/2012 03:54 AM, Nat Sakimura wrote:
> Thanks Justin. This is very useful.
> One of the shortcoming of the OAuth 2.0 is that it does not define
> authentication endpoint explicitly.
I actually see that as a key feature -- it keeps OAuth out of the
business of end-user authentication and lets it sit in concert with
whatever kind of primary authentication scheme you might want.
> In OAuth, client goes to
> authorization endpoint, and if he is not authenticated at the time, he
> is redirected in a proprietary protocol to the authentication
> endpoint. Then, the user provides credentials to get authenticated,
> and returned to another endpoint, likely to be the authorization
> endpoint, through yet another proprietary protocol, to authorize the
> resource access.
> My interpretation of what you have done here is to use OpenID Connect
> instead of the proprietary protocol above.
Exactly right. What was confusing to some of the people that I've been
talking to is that OIDC uses OAuth2 under the hood, so they were
conflating the authorization delegation with the primary authentication
to the AS. The fact that the AS is both an OAuth2 server and an OIDC
Client (and therefore an OAuth2 client) wasn't quite sinking in, so I
drew some pictures to help explain it. I think better with pictures, too. :)
> By delegating the authorization to the OIDC server would optimize the
> authorization, especially when there are multiple resources from
> different domains are involved. That's what UMA is trying to solve, I
Yes, you can do it this way -- but only if the RS knows how to talk to /
trust the IdP in my diagram. That is indeed what UMA is trying to solve.
But with at least some of the systems that we're working with, that's
not likely to happen due to policy and configuration rules as they stand
right now. This becomes especially clear if you've got a case where the
RS and AS are in the same box and are using a random, unstructured token
-- the default case for most OAuth2 server libraries.
Happy that people find it useful,
On Fri, Sep 7, 2012 at 11:42 PM, Justin Richer <jricher at mitre.org> wrote:
>> We've been working on a system that makes use of both vanilla OAuth2 and
>> OpenID Connect to bridge between two security domains. One of our immediate
>> applications for this is in the healthcare space (a doctor's system
>> requesting a medical record from another doctor's system), but we're finding
>> that the pattern is very useful across a multitude of different deployments.
>> The setup is fairly simple and shouldn't surprise anyone in this group:
>> somebody wants to authorize a client to access data, so they do the OAuth
>> dance and get sent to the AS. But in order to log into the AS, they use a
>> distributed ID protocol like OIDC. What I've found that confuses people is
>> that the AS, in this case, needs to act like an OIDC client (and therefore
>> OAuth2 client) in addition to being an OAuth2 server in its own right.
>> With that in mind, I've put together a PDF that lays out, in annotated
>> detail, all of the steps that need to occur, and who needs to talk to whom:
>> -- Justin
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab