GeezerVison

Summary

• microsoft is excluded from accountLinking.trustedProviders because the email claim is attacker-controllable on /common/ (nOAuth). Entra never emits email_verified for work/school accounts, so Better Auth refused to link a Microsoft identity onto any existing user row — those users hit account_not_linked permanently, with no recovery path
• Derive emailVerified from Entra's xms_edov optional claim, emitted only when the email's domain belongs to the user's tenant and an admin verified that domain. It's the one email signal a hostile tenant cannot forge, and it's Microsoft's documented nOAuth mitigation. microsoft stays untrusted — the linking guard now passes on its own merits
• The mapper returns {} when unverified, so it only ever promotes unverified → verified, never downgrades. With the claim absent, Better Auth's computation is byte-identical to today
• Add prompt=select_account, so /common/ stops silently reusing whichever Microsoft session the browser already holds
• Add /oauth-error copy for account_not_linked and email_not_found, which currently dead-end on "Please try again" — advice that can never succeed

Requires an Entra change to take effect

Inert until xms_edov and email are added as optional claims on the ID token for the app registration (xms_edov requires email to be present). Until then the mapper returns {} and behavior is unchanged.

Known limitation: xms_edov is false for SAML/WS-Fed federated domains and for B2B guests, so those tenants remain unlinkable and should use Entra SSO, which is trusted for linking.

Verified against the Better Auth source

• callback.mjs:140-152 passes getUserInfo's result into handleOAuthUserInfo; microsoft-entra-id.mjs:91-107 builds it from decodeJwt(idToken), so xms_edov is visible to mapProfileToUser, whose result is spread last (:116)
• overrideUserInfoOnSignIn is unset, so the branch that rewrites email/emailVerified on every sign-in (link-account.mjs:67-77) never runs
• Existing Microsoft users get emailVerified upgraded on next sign-in (link-account.mjs:49,65), guarded on exact email match — an upgrade, never a downgrade
• Welcome email fires exactly once: today Microsoft users get none (auth.ts:348 gates on emailVerified); after this they get one at creation. afterEmailVerification only runs in the verification flow, which OAuth signups don't enter — no duplicate
• The OAuth verification-email branch (link-account.mjs:105) needs both sendOnSignUp and sendVerificationEmail; we set neither, so it stays dead
• Integration connectors are untouched — they're genericOAuth entries with their own providerId and getUserInfo

Type of Change

• Bug fix

Testing

bun run type-check clean; 297 tests across 18 files in lib/auth + lib/oauth pass; verified the new tests fail when the mapper is stubbed out.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)