[Bug]: OAuth unable to bind email to user

[placidic]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I have a successful GENERIC OAuth Implementation for Lowcoder against Microsoft Entra ID.

When a new user is created automatically upon first login of the user, the new lowcoder-user object is not populating the email property. Furthermore, if the logged in user clicks the Profile Icon and attempts to manually bind the email address to the current user, an "Oops, service is busy" error message appears and the binding fails.

I can confirm that the GENERIC data contained in the user object contains the email address value - but the local user email is blank.

With the new Lowcoder login experience in v2.5.0, this is causing issues when the user is trying to log in using the standard user login path. The email is unable to be found in the local lowcoder database and stops the user from proceeding.

There is a workaround however to still use the old workspace specific login path - once you go there, you still only see the Email Input, but if you enter an email address and click "Continue" it then refreshes and renders the SSO Buttons configured for that workspace. An extra step to log in now with 2.5.0, but at least accessible.

Expected Behavior

I would expect that upon first login of the new user, the email address returned from the OAuth provider would be automatically bound to the lowcoder user object.

Steps to reproduce

1. Set up Generic OAuth Provider with MS Entra ID - using 'email' for email binding
2. Obtain an Invite link for a new user
3. Log in using the invite link via SSO for the new User
4. Log out and try to log back in using the email address returned from the SSO Binding

Environment

Lowcoder 2.5.0 Self-Hosted

Additional Information

No response

[FalkWolsky]

We have a question: Did you use the mapping in Step 3 and map by a JSON path the field eMail?
Please have a look here. Either the access_token or the userInfo Endpoint have the eMail in the JSON objects available. By this binding and a classic JSON notation like user.data.email (just as example) - you can address the eMail and it will get bound automatically.

[placidic]

I do have it mapped:

And if I look at my currentUser state, it shows the email under the GENERIC attributes:

After inspecting my jwt token, i then realized that there was no 'email' property returned in my token!
My assumption is that the email is getting returned during the user introspection call after authorization.
Although i'm sending the scope for 'email' it just allows permissions to it, but does not return it in the initial token response.

Would it be possible to update the local email address based on the result of a user introspection call in the case that user introspection is enabled?

At least I think i know why its not working =)

[FalkWolsky]

This is actually what we (aim) to do. If we do not find the eMail based on the JSON Path you entered there - but if we then get the JSON by the user introspection Request, we take the eMail from there. Please check the JSON structure of the user introspection endpoint and adapt the JSON path in the Source Mapping as you expect all fields there would come from the user introspection endpoint

[FalkWolsky]

Idea behind this "manual binding" is to give great flexibility for many possible providers and integrations.

[placidic]

I'll try out a few variations and confirm. What's odd is that the current name of the email returned from user introspection is 'email' based on what shows under the extras=>GENERIC section under the currentUser object, which is how I have it mapped in the source mapping.

Thanks for the feedback and I'll let you know!

[FalkWolsky]

We also have to try again. If it not works as intended - then we will fix it.