Power Platform Community Forum Thread Details

I have the custom IDP hooked up to my Microsoft PowerPages website via OIDC. However after successful sign-in through the IDP, even though the email claim is precisely mentioned to be returned, there is none in the id_token. IDP side settings are to be set as an implicit flow and PowerPages side I have put in scopes openid email but nothing is returned (reflects the wellknown file). What I have also tried is playing around with the response type. The IDP allows all of them, however if I put only code I get a SAMLresponse with all the information I actually need, the issue is there is no way to hook it up to the registration claims of Dataverse (or even for Dataverse to know how to do the contact mapping). If I select code and id_token it throws a external sign in failure. If I select id_token token I get the id_token and the AccessToken. I do not know how to proceed but I think from the above the code response type beared the most fruit, the issue is how to relate it to the Dataverse column via the registration claims.

Categories:

Settings

General

Hi ChompingBot ,

Thanks for sharing the details of your issue with setting up SurfConext as a custom IDP via OIDC in Power Pages. It sounds like you're running into a common challenge where the email claim isn't appearing in the id_token despite your configurations, and you're experimenting with response types to get the right data for Dataverse contact mapping. I'll break this down based on what I've seen in similar setups and suggest some troubleshooting steps to help resolve it.

Understanding the Issue
From what you've described, Power Pages expects an email-related claim (named 'email', 'emails', or 'upn') to be present in the id_token for proper authentication and mapping. SurfConext, as an OIDC provider, follows a minimal disclosure policy, which means it only includes claims in the id_token if they're deemed essential or explicitly requested—non-essential ones might be omitted unless configured otherwise. This could explain why your email claim isn't showing up, even with scopes like 'openid email' set on the Power Pages side.

Additionally, your tests with response types are insightful:

Implicit flow (id_token or id_token token): This returns the id_token (and possibly an access token), but claims might still be missing if not populated by SurfConext.
Code flow: You're getting a SAML response with the needed info, but Power Pages is built for OIDC, so it doesn't natively handle SAML for claim mapping to Dataverse contacts. The "external sign-in failure" with 'code id_token' suggests a mismatch in flow expectations.
The well-known endpoint reflection indicates your OIDC metadata is correct, but the claim isn't being issued.

Suggested Troubleshooting and Solutions
Let's focus on getting the email claim into the id_token first, then handle the Dataverse mapping. Here's a step-by-step approach:

Verify and Request Claims in SurfConext:
- Log in to your SurfConext dashboard and ensure the email claim is marked as essential for your service provider (Relying Party). You can use the 'claims' request parameter in your OIDC authorization request to explicitly ask for it in the id_token, like: {"id_token": {"email": {"essential": true}}}.
- SurfConext supports all OIDC flows, but they recommend the code flow with PKCE for security—test enabling claims in the id_token directly via their support if it's not working. Avoid relying on the userinfo endpoint alone, as Power Pages prioritizes id_token claims for authentication.
Adjust Power Pages OIDC Configuration:
- In Power Pages, go to Security > Identity providers > [Your OIDC Provider] and confirm the scopes include 'openid email'. Under Additional settings, try setting the response mode to 'form_post' if it's not already, as this can help with token delivery.
- For response types, stick to 'id_token token' for implicit flow to get both tokens without errors, and ensure your reply URL matches exactly.
Mapping Claims to Dataverse Contacts:
- Once the email claim is in the id_token, use Registration claims mapping in Power Pages to link it to Dataverse fields. For example, set it as emailaddress1=email (or whichever contact field you need, like emailaddress2=email if testing alternatives).
- If you're still getting a SAML response in code flow, you might need to convert your setup to pure OIDC—Power Pages doesn't support direct SAML mapping to registration claims, so focus on getting OIDC working fully.
- Test by registering a new user and checking the created contact record in Dataverse for the mapped fields.
Testing and Debugging:
- Use tools like the OIDC Playground (mentioned in SurfConext docs) to simulate requests and inspect tokens. Also, enable verbose logging in Power Pages or check the portal's audit logs for claim-related errors.
- If custom scopes are involved, Power Pages supports them, but ensure they're defined correctly in SurfConext and not causing conflicts.

If these steps don't resolve it, I recommend reaching out to SurfConext support for provider-side confirmation on claim issuance, or posting more details (like your exact OIDC metadata URL) in the Power Platform community for peer input. I've helped with similar Azure AD B2C and OIDC setups before, so feel free to share any error logs or configs for more tailored advice!

Best Regards,
Jerald Felix

Community site session details

Custom IDP (SurfConext) set-up via OIDC does not return email claim in id_token

Helpful resources

News and Announcements

Quick Links

Responsible AI policies

Tom Macfarlan – Community Spotlight

Congratulations to the September Top 10 Community Leaders!

Leaderboard > Power Pages

Featured topics

Product updates