Help Needed: Custom OIDC Provider (LinkedIn) in Entra External ID - AADSTS40015 after successful Postman test

Hello everyone,

I'm trying to configure LinkedIn as a custom OpenID Connect (OIDC) provider in my Azure Entra External ID (CIAM) tenant, but I'm stuck on the final step. I've gone through several stages of troubleshooting and can confirm that the LinkedIn application setup is correct. I'm hoping someone can shed some light on the final error.

Here is a summary of my journey so far:

Phase 1: Initial Configuration & "Well-Known" Endpoint Error

My first attempt to add LinkedIn using their well-known OIDC configuration URL failed with a validation error in the Entra ID portal: Required property 'token_endpoint_auth_methods_supported' not found in JSON.

• Solution: I copied the JSON from LinkedIn's endpoint, manually added the missing token_endpoint_auth_methods_supported": ["client_secret_post"] property, and hosted the corrected file on a public Gist. Using this new URL as the "well-known endpoint" allowed me to successfully save the identity provider in Entra ID.

Phase 2: Silent Login Failure (No Sign-in Logs)

After configuring the provider, I added it to my Sign-up/Sign-in User Flow. The LinkedIn button appeared correctly on my login page. However, the login process would fail silently:

I was correctly redirected to LinkedIn.

I authenticated and granted consent.

I was correctly redirected back to the ...ciamlogin.com/.../federation/oauth2 URL.

The page would load, but I was not logged in.

Crucially, no entries appeared in the Entra ID Sign-in logs, making it impossible to debug.

Phase 3: Deep Dive & Successful Manual Test

To isolate the problem, I performed a full manual test of the OIDC flow:

Browser Network Trace: I confirmed that LinkedIn was correctly redirecting my browser back to the correct redirect_uri (https://<my-tenant>.ciamlogin.com/<tenant-id>/federation/oauth2) with a valid code and state parameter.

Postman Test: I used the authorization_code from the browser trace to make a backend token exchange request in Postman. This request was 100% successful. I received a valid id_token and access_token from LinkedIn.

Token Validation: I decoded the id_token on jwt.io and confirmed the iss (Issuer) claim (https://www.linkedin.com/oauth) perfectly matched the Issuer URI configured in Entra ID.

This proves that my LinkedIn App configuration (Client ID, Client Secret, and Redirect URIs) is correct.

Phase 4: Current Error - AADSTS40015

After testing in a private browser window (to rule out cookie/cache issues), the silent failure disappeared and was replaced by a specific error message in the URL:

error: server_error

error_description: AADSTS40015: The identity provider returned an error.

Trace ID: 082a5b26-cbc5-40d1-8f61-a9f5be230800

Correlation ID: 281139ab-b0cb-4d43-b74b-a1ac5b586827

This error tells me that Entra ID is now successfully communicating with LinkedIn's token endpoint, but LinkedIn is returning an error to Entra's backend call.

My final troubleshooting step was to address a potential ambiguity in the Redirect URIs. The Microsoft documentation advises registering two similar URIs. I tested by having only one of them registered in the LinkedIn App at a time, but the error persists.

My Question

Why would LinkedIn's token endpoint return an error to the Entra ID service (AADSTS40015), when a manual Postman request using the exact same credentials (client_id, client_secret), grant_type, and a valid code works perfectly?

It seems like there is a subtle difference in the server-to-server token request made by Entra ID compared to a standard tool like Postman. Has anyone encountered this before?

Any insights would be greatly appreciated. Thank you!