Just wondering if im doing anything wrong before opening an issue. Creating a Microsoft Entra ID identity provider, returns an error "This providerId is reserved and cannot be used for an SSO provider". I'm wondering if the underlying OIDC auth library has reserved the providerid "EntraID"

fyi I looked deeper and it is a bug after update to better auth. I opened issue: github.com/archestra-ai/archestra/issues/7410

Theres a bunch of other bugs ive found related to OIDC SSO that have hard coded workarounds only for Google OIDC. Im guessing this is because you test against your own Google instance.

I'll open a few issues for them.

hey 👋 thanks for reporting this. I'll take a look and we'll get a patch out in the next release (v1.3.43).

(better-auth had some upstream issues/limitations around "custom identity providers" which we had to work around - but it looks like in v1.6.22 they addressed these, unfortunately we were missing some regression tests which would've caught this 😅)

which workarounds are you referring to? if you can open an issue with more details would be happy to address this as well

Sorry new baby, didn't get time to lodge them. I'll try and use Claude to put something together. From what I saw Google is the only one that asks for domain, the others don't. I had to add in an extra claim to to bring in the verified domain = true to get existing user accounts to match.

I think I passed that into email verified

I don't want to post this as an issue cos it's just Claude slop, I'll lodge a proper one in the morning if needed. One arm is occupied rocking a 6 day old to sleep

Signing in through a configured Entra ID OIDC provider fails with account not linked whenever the email belongs to an existing user. New users can sign up through the same provider fine.

Better-auth allows implicit linking if the provider is trusted or the IdP says email_verified: true. Entra fails both here.

The trust check can't pass for anything except Google. For SSO providers, trusted means domainVerified === true and the sign-in email's domain matches the provider's domain column. The trustedProviders list from getTrustedAccountLinkingProviderIds isn't consulted at all, since the SSO plugin calls the linking handler with trustProviderByName: false. The domainVerified half is fine (the workaround in IdentityProviderModel.create sets it), but normalizePersistedAllowedEmailDomain writes an empty domain for every providerId except "Google", and an empty domain can never match. So trust is false for every non-Google provider.

That leaves email_verified, and Microsoft doesn't send it. Not in v2.0 ID tokens, not from Graph's oidc/userinfo. Okta, Google and GitLab all send it, which is why linking looks fine everywhere else and this went unnoticed.

My workaround: add the xmsedov optional claim to the ID token in the Entra app registration, set oidcConfig.mapping.emailVerified to xmsedov, and drop userInfoEndpoint so claims come from the ID token (userinfo can't see xms_edov). The mapping field is in the schema but the form doesn't expose it, so it has to go in via the API.

Suggested fix: persist the allowed email domain for all providers instead of only Google, and show the field for all of them. The trust branch then works everywhere and linking stops depending on which IdPs happen to emit email_verified. It would also extend the assertSsoEmailDomainAllowed sign-in filter, currently Google-only, to every provider.

While I was in there: the TODO on the domainVerified workaround cites better-auth#6481 as pending, but that's closed and #6551 made the strict linking permanent, so the comment is stale. The dynamic trustedProviders from #7904 is wired up but does nothing for SSO linking on @better-auth/sso 1.6.22, per the trustProviderByName: false behaviour above

Looks like it didn't add in you have to remove the userinfoendpoint url in the OIDC config when doing the workaround

The addional claims for entra aren't returned there, only in the token