Looking for workaround for GitHub's email hiding.

[mou]

Hi, FusionAuth community.

We are trying to integrate GitHub as an IDP. Since we are using emails for account linking, we faced a very well-known issue with users' ability to hide their emails from API user resources. But GitHub is really important for us and I am on the quest to find possible solutions. So I have two ideas, and want to validate them with the community's help.

Currently, I have two ideas:

• try to perform GitHub /user/emails API call from the reconciliation lambda
• attempt to detect such conditions and alter error messages on a template level, to display more relevant information about the issue and link to the guide on how to make things work.

Is it even possible? Or maybe you have another workaround for this case?

[dan]

Hiya!

@mou said in Looking for workaround for GitHub's email hiding.:

try to perform GitHub /user/emails API call from the reconciliation lambda

I don't think that will work based on a scan of https://docs.github.com/en/rest/users/emails?apiVersion=2022-11-28 . That endpoint provides info about the current logged in user, unless I'm missing something.

attempt to detect such conditions and alter error messages on a template level, to display more relevant information about the issue and link to the guide on how to make things work.

You could also look at using a lambda to create a made up username for the user: https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile#modifying-email-and-username-claims

And then in your application, check for that made up username (or a different claim) and force the user to provide an email address before accessing to your system.

[mou]

Thank you, @dan for your suggestion. I consider your idea. But in this case, we need to decide to change the linking strategy. If it set to email, this approach will generate new users, rather than linking social login.

@dan said in Looking for workaround for GitHub's email hiding.:

I don't think that will work based on a scan of https://docs.github.com/en/rest/users/emails?apiVersion=2022-11-28 . That endpoint provides info about the current logged in user, unless I'm missing something.

I thought it could be possible because reconcile Lamba would receive a user access token as a parameter. At least such an idea appeared when I saw the lambda signature.

[dan]

But in this case, we need to decide to change the linking strategy. If it set to email, this approach will generate new users, rather than linking social login.

Sure, that would be a problem. You'd need to store the GH login id and make sure the user associated it somehow. It's a thorny problem because at the end of the day, the user has decided not to make their email available.

I thought it could be possible because reconcile Lamba would receive a user access token as a parameter. At least such an idea appeared when I saw the lambda signature.

I don't see where the user access token is presented to the GH api. Maybe I'm missing something.