Hi everyone,
I've recently configured SSO using OIDC with Azure AD as the Identity Provider in our OutSystems application (Achiever). The authentication flow itself is working fine — users can log in successfully. However, the email claim is not being returned in either the ID Token or the UserInfo response.
Here's what I've done so far:
The issue: After successful authentication, when I try to access the user's email in OutSystems (e.g., through the GetExternalUser action or the User record), the email field comes back empty or null. Other claims like name and sub are returned correctly.
What I've already checked:
My questions:
Any guidance, workarounds, or similar experiences would be really helpful. Happy to share more details like token payloads (redacted) or configuration screenshots if needed.
Thanks in advance!
Hi @Afonso Metello,Thanks for the response,It is sorted now; Issue was on Mapping the Email in User table.I tried the suggestions given by you as well, infact i was doing the same things earlier.Anyways got the solution as of now through the Identity Provider configuration.
1. Go to ODC Portal > Manage > Identity providers > Azure AD configuration
2. The claim mapping for the Email attribute
3. It was set to email, but my token decode shows the address in preferred_username, so i changed the mapping to preferred_username
4. Mapped the Email in User table as well and it worked.
Thanks :)
Hi Varun,
Quick note before diving in: your post is tagged ODC, but you mention GetExternalUser and the User record, which are O11 patterns. I'll cover both so you can move forward immediately regardless.
The root cause (applies to both platforms)Azure AD v2.0 endpoints do not include the email claim in the ID token by default, even when you've added the optional claim — which helps, but only for users whose mail attribute is populated in Azure AD. For cloud-only users or synced accounts without a mailbox (Exchange Online), the claim is silently absent from the token. In my experience, the email address is almost always in preferred_username or upn, not in email.One nuance worth noting: preferred_username typically contains the user's UPN, which looks like an email address and usually matches the real email, but is not guaranteed to be the actual email address. In most organizations they are the same, but verify this is acceptable for your use case.Diagnostic step first (do this regardless of platform)
Decode your actual ID token at jwt.ms or jwt.io and look specifically for email, preferred_username, and upn. This tells you exactly what Azure is sending and removes the guesswork from the platform config.
If you're on ODC
ODC maps OIDC claims to User entity attributes (Id, Name, Email, PhotoUrl) through the Identity Provider configuration.
1. Go to ODC Portal > Manage > Identity providers > your Azure AD configuration
2. Find the claim mapping for the Email attribute
3. If it's set to email but your token decode shows the address in preferred_username, change the mapping to preferred_username
4. If the address appears in upn, use upn instead
Whether ODC hits the /userinfo endpoint depends on how the OIDC connector is configured, but the ID token is the first place to check.
If you're on O11
SSO with Azure AD in O11 is typically handled via the IdP Forge component or the Users module OIDC configuration. The claim mapping lives in the IdP component's Config_UserMappings entity.
1. Open Service Center or Service Studio and locate the IdP configuration data
2. Check the Email_Attribute field — it may be set to email
3. Change it to preferred_username
4. GetExternalUser reads from the User entity, which is populated based on this mapping — so fixing the attribute name here is the fix end-to-end
Azure-side hardening (applies to both)
If email is missing from the token entirely after the decode:
1. Azure AD > App Registration > Token Configuration: add email and upn as optional claims for both ID token and Access token
2. Azure AD > App Registration > API Permissions: ensure the email and profile delegated permissions have admin consent granted
This increases the likelihood of the claim being present, but note it won't help for users without Exchange Online mailboxes. For those users, preferred_username is your only reliable option.
Let me know which platform you're on and how the token decode goes.