K
Kinde2w ago
Joo

github provider not giving email address

So for a GitHub user that has emails set to private, is it just impossible to get their email address? My project has email read permissions and asks for authorization, but when I access the kinde user info I'm not getting any email address for the user.
10 Replies
David Bainbridge
Hi there, If a GitHub user has set their email address to private, it is expected that the email field will not be returned—even if your application has been granted email read permissions. This behavior is controlled by GitHub, so even with proper authorization, the email won’t appear if the user opts to keep it hidden. Let me know if you need further clarification or have additional questions
Joo
JooOP2w ago
@Ages then how come I can see that info from the kinde web app? @Ages it seems that the github email address and username IS somehow stored on the kinde end but not exposed, because i can see it in the web portal. when i call the management api and search for the user, i can get the github id from identities but no other information. can you just expose whatever it is you're doing to get this info??? i mean really what you should do is just tie the github email to the user on kinde end because you clearly have it it's showing up directly in the web portal
TotalScrub
TotalScrub2w ago
The Kinde documentation states (I don't have the exact reference here) that what you can see via the Management UI should be visible in the API. I agree with you Joo, that looks like a bug.
David Bainbridge
Hi Joo, Thanks for flagging this. I understand your concern regarding the discrepancy between what’s visible in our Management UI and what’s returned via the API. The intended behavior, as outlined in our documentation, is for the data visible in the UI—including the GitHub email address—to be accessible via the API. This inconsistency appears to be a bug, and I have escalated it to our engineering team for further investigation. I’ll update you as soon as we have more information or a fix in place. In the meantime, if you have any further details or questions, please feel free to share. @Joo What endpoint are you hitting that isn't returning the email?
David Bainbridge
Hi Joo, We've been looking into this and would like to confirm a few details. 1. Could you share the exact API endpoint you're using to retrieve user details? This will help us verify if the email field is expected to be returned there. 2. Can you check if the social identity scope is enabled in the ID token configuration? If it's not included, it might explain why the email is not appearing in the API response. You can refer to this Kinde documentation for more details. Let us know what you find, and we’ll continue troubleshooting from there.
Kinde docs
ID tokens
Our developer tools provide everything you need to get started with Kinde.
David Bainbridge
Hi Joo

Based on our findings, when GitHub does not provide an email address (e.g., if the user's email is set to private), Kinde prompts the user to enter an email manually. This email may not necessarily match their GitHub email, as we don’t have access to it. Additionally, the email captured this way is not automatically linked to the social identity in our system, which might explain why it's visible in the Kinde Management UI but not exposed via the Management API. Let us know if this helps clarify the issue or if you need further assistance
Joo
JooOP2w ago
In response to the questions in order:
What endpoint are you hitting that isn't returning the email?
https://boolai-oryx.us.kinde.com/api/v1/user query parameters: user id: {user_id} expand: 'identities' result w/o user info:
{
"id": "",
"picture": "",
"last_name": "",
"created_on": "",
"first_name": "",
"identities": [
{
"type": "oauth2:github",
"identity": "{github_id}"
}
],
"is_suspended": false,
"last_signed_in": "",
"total_sign_ins": 5,
"failed_sign_ins": 0
}
{
"id": "",
"picture": "",
"last_name": "",
"created_on": "",
"first_name": "",
"identities": [
{
"type": "oauth2:github",
"identity": "{github_id}"
}
],
"is_suspended": false,
"last_signed_in": "",
"total_sign_ins": 5,
"failed_sign_ins": 0
}
I get the github id only but no other info.
Can you check if the social identity scope is enabled in the ID token configuration?
Please kindly point me to where this exists, as there is no scope with any mention of "social" in the manage scopes ui for tokens. I have read:identities and read:user_identities scopes enabled.
Based on our findings, when GitHub does not provide an email address (e.g., if the user's email is set to private), Kinde prompts the user to enter an email manually. This email may not necessarily match their GitHub email, as we don’t have access to it. Additionally, the email captured this way is not automatically linked to the social identity in our system, which might explain why it's visible in the Kinde Management UI but not exposed via the Management API.
That's the opposite of what I'm seeing - I have the user who doesn't have an email address, but the github connection shows the email. For the user under "identities" there exists only "social", no "emails", and the one entry for social is "github" with the user's github attached email inside the github card.
Joo
JooOP2w ago
No description
Joo
JooOP2w ago
And if it were the case that it was linked to the User but not the social identity, I should still be able to see it on the user somewhere. But there's no email anywhere on the user
David Bainbridge
Hi Joo, Thanks for providing the details and screenshots. We're reviewing the issue and will update you as soon as we have more insights. In the meantime, feel free to share any additional observations. Hi Joo

It looks like the issue may be related to the "Trust email" setting in your GitHub configuration within Kinde. If this setting is not enabled, Kinde does not automatically populate the GitHub email for users. To resolve this, please check your GitHub settings in Kinde and ensure that "Trust email" is turned on. Once enabled, it should pull the email through for future user sign-ups. Additionally, there's already a fix in place that ensures emails are populated for sign-ins if the setting was previously off but later turned on. Let us know if you need further assistance

Did you find this page helpful?