Calling FusionAuth get user API from an OpenID Connect lambda function

tim 0

I have a third party OpenID Connect IDP I'm trying to integrate with FusionAuth. The issue is that an email is never provided in the initial JWT or in the subsequent call to the Userinfo endpoint. They do provide a user ID in the initial JWT in the 'sub' claim and in the subsequent Userinfo call. My plan would be to use an OpenId Connect reconcile type lambda like so.

user.userId = jwt.sub;
userObj = API call to fusionAuth passing jwt.sub;
if (userObj == null) redirect to app signup page
else user.email = userObj.email;

I'm not sure how to make that call to the fusionAuth API or if it's possible or even if this approach will work.

Thanks for the pointers

dan

Hiya,

If you don't have an email address provided by an OIDC endpoint, but you do have a unique value that is the same for a user over time, you can create a mock email address, as documented here: https://fusionauth.io/docs/v1/tech/lambdas/openid-connect-response-reconcile#workarounds

Does that workaround work for you?

You can't call any APIs from within a lambda. This is an open feature request: https://github.com/FusionAuth/fusionauth-issues/issues/267

Within a lambda you are pretty much limited to modifying javascript objects; you can't intervene and redirect a user.

tim 0

I did see and try that work around which led me here. The issue is our users are already present in the fusionAuth DB and creating new users with a unique ID that doesn't match isn't great. Our application required email as user name and we enforce that so when creating new duplicate users the new email would create a conflict in fusionAuth?

The flow I'm trying to achieve is:

OpenID back and forth
After call to userInfo check for unique userID in fusionAuth DB
If userID exists login as that user
if userID does not exist redirect to application user creation page

dan

Hiya @tim-0

I'm not sure I understand your flows. It sounds like you want to handle two use cases.

Use case #1 User is not in FusionAuth system, but is in the OIDC system. You want them to authenticate via the OIDC provider. Then they should register with FusionAuth. Then, going forward, they should authenticate against FusionAuth. Or maybe against the OIDC system too? Not clear.

Use case #2 User is in the FusionAuth system. They should still be verified against the OIDC system somehow but then shown a different page, no registration needed? After that, they'll auth against FusionAuth? I'm confused here because I don't know why they'd need to be verified against the OIDC system here.

Maybe it's worth taking a step back and explaining what you are trying to accomplish. Which system is going to be the system of record for the users. The OIDC system or FusionAuth? Do you have multiple applications in FusionAuth and the OIDC system only is used for one of them?

If you could lay out in detail the flow of the different user paths, I might be able to understand things a bit better.

Thanks!