0

Is there a usage of OpenID Connect (OIDC) that allows for a chain of RP (terminology reference)

user -> RP#1
user <-redirect to chosen OP- RP#1
user -> OP: verifies identity
user <-redirects to RP#2- OP
user -> RP#2
user <-Signs this attestation and redirects to next RP in the chain- RP#2
user -> RP#1: Has an authenticated user by an OP, that is asserted by some other RP

The public component of RP#2's key could live at some /.well-known [link] path on RP#2

Why would someone want this?
It's useful if you need to authenticate a user from some other system that does not implement OIDC.

3
  • Where / how is the chain determined? Dec 21, 2020 at 16:01
  • Open to suggestion, but I'd assume this would be defined by RP#1 as they are indifferent on the OP choice but do want to know that RP#2 is in agreement.
    – JoeKir
    Dec 21, 2020 at 16:07
  • Since OIDC defines the protocol between an RP and OP, and otherwise doesn't prescribe what steps the OP should take to produce an ID token, the OP is free to call other OPs. The ID token returned to the RP could embed the assertion (a JWT or something else) from the second OP. If the RP is to orchestrate this chaining, a special scope value could be defined to signal this intent to the OP. Dec 21, 2020 at 17:21

1 Answer 1

0

This is why we use the passport-js component in Gluu--for inbound identity. You can find docs here.

user -> RP#1

user <- redirect to chosen OP (Gluu Server oxAuth component)

So I'm assuming here that the RP has published several "buttons", like "Login with Google", "Login with SAML IDP ABC", "Login with Github"... and that the user selects the OP of his choice. If this is the case, the RP#1 is performing "Discovery". That's good...

The trick here is that you are going to redirect to only one OP--your Gluu Server (really the oxAuth component of Gluu), using an OpenID Connect Authn Request, specifying the right parameters, especially

"acr_values=passport_social&preselectedExternalProvider="

The idea is that you are giving a hint to the Gluu Server as to which OP you want the user redirected to for authn.

There's a little more to it, so read the docs. But hopefully you get the idea

user -> OP: verifies identity [at his chosen IDP] user <-redirects to RP#2- OP user -> RP#2 user <-Signs this attestation and redirects to next RP in the chain- RP#2

It's a tad unclear here. Post authn, the Gluu Server (oxAuth) returns a signed JWT per OpenID Connect--i.e. an id_token, with details of the authn event. In the passport-social authentication script, you the opportuuntiy to redirect to another RP if you like after the social authn happens. You could also implement extra steps in the consent phase, or the post-authn phase of the authentication workflow.

user -> RP#1: Has an authenticated user by an OP, that is asserted by some other RP

voila!

Note, you should also check out the Janssen project, although this is just OpenID Connect, and does not include passport-js of course. The Gluu Server is an integration of several open source components. In this case, you see why that's handy. In Gluu 4.x oxAuth is the OpenID Provider. In Gluu 5.x (coming soon), we'll migrate to Janssen (which is basically the same thing, but the project is now governed at the Linux Foundation).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .