Hi, Luis. As far as I can remember, the mapping itself happens within the Jython script, it doesn't done by Passport. So theoretically you could customize mapping behaviour to suite your needs. I suppose you are trying to configure Inbound OpenID Connect strategy? Have you already tried it out without providing `/userinfo` endpoint, and it failed?

> So theoretically you could customize mapping behaviour to suite your needs. I understand. I was trying to keep it as vanilla as possible, regarding the mapping. That's why asked about the `sub` matching gluu's internal user id (which I believe is `uid` from gluu's perspective) > have you already tried it out without providing /userinfo endpoint, and it failed? Yes. I've tried it without defining the `/userinfo` endpoint and the auth flow seems to hang after the user comes back from the inbound provider with the `code`. I can see from our logs that the `code` was exchanged for a token successfully, which further supports this theory. However, I can't see anything in the Passport logs that mention any missing `/userinfo` endpoint or even a `connectTimeout`, which I would expect if Passport can't hit that endpoint and it gives up. Is there any configuration I can tweak to get more verbose logs from Passport? Bear in mind I'm using the pygluu-compose script to start up the gluu stack.

What is the value of the subject claim? Is it the phone number?

First I used the `inum` field, but I've changed it to the `username`. For some extra context, before we do any phone verification we query for gluu Users through the SCIM API e.g. `filter=phoneNumbers[value eq '555555']`. This is so we can build the ID token with the right set of claims and hopefully Passport will say "yeah, this `sub` exists and it's not an external identity". However, like I've mentioned in my initial post, it seems that it requires a `/userinfo` endpoint to be defined when we register the Provider. Would you be able to clarify if that is the case, or could it work with just reading the ID token claims?

As Alex pointed out, we don't recommend any of this business logic in passport-js. We just use passport to normalize the authn/claims. But what is the sub coming in from the external IDP? I'm not sure if passport-js passes the id_token itself from the external IDP.

So from what I understood: * if I want to do something like "there's this inbound identity with a given `sub`, check if it matches an internal gluu user `inum` or `username` and log them in", I have to do that through the Jython script? * Passport is simply managing the auth flow before the normalized claims are sent to the Jython auth script? * Passport requires a `/userinfo` endpoint to be specified (maybe?) > But what is the sub coming in from the external IDP? The `sub` coming in would be the gluu `inum`. We play the role of the external IDP. We don't actually own or store any identity, thus the SCIM API query to gluu. My initial integration idea was: * you create an OIDC client on our side (tru.ID) with a `redirect_uri` that points to your gluu installation * you configure an Inbound Identity Provider on gluu, with the credential information obtained from the previous step * you run a sample app that will handle the phone verification flow Then all the user has to do to login with their phone is: * when presented with the gluu auth screen, click the new Provider entry to login * they would be redirected to a tru.ID page to input their phone number * perform the phone verification * on result, they would be redirected back to gluu, so their external identity could be mapped to an existing gluu User

You may be making this more complicated then it has to be. Is the goal 1) to introduce an OpenID Connect interface for Tru.id SaaS service or... 2) to enable customers with a Gluu Server to be able to use Tru.id for authentication / enrollment?

That is quite possibly the case. I would say: We want to offer an OpenID connect interface to make it easier for customer to leverage a SIM based authentication factor.

Ok, then I wouldn't worry about setting up a Gluu Server as a customer demo.... I would just setup a simple mod_auth_openidc client to show that a client can use Tru.id as an OpenID Provider. Configuring inbound identity is a pain in the neck, and it's just not worth it for a demo here. Ultimately, the customer will more likely be using Okta. So net-net, I think you're almost done :-)