Following Supabase's own documented setup for Azure sign-in with personal Microsoft accounts (Login with Azure docs, "Configure a tenant URL" section: "If your app is registered as Personal Microsoft accounts only for the Supported account types set Microsoft tenant to consumers"), the OAuth flow completes successfully on Microsoft's side - the user reaches the consent screen, approves, and is redirected back with a valid code - but the callback then fails with:
?error=server_error&error_code=unexpected_failure&error_description=Error+getting+user+profile+from+external+provider
This is the same symptom described in #1549 (title: "Error getting user email from external provider only with public Azure /consumers/ tenant"), which appears to have gone unresolved.
To Reproduce
Register an Azure AD app with Supported account types = "Personal Microsoft accounts only" (signInAudience: PersonalMicrosoftAccount, confirmed via the raw app Manifest, not just the portal UI summary)
In Supabase's Azure provider settings, set Azure Tenant URL to https://login.microsoftonline.com/consumers (exactly as documented)
Client ID/Secret entered correctly, redirect URI matches exactly what's registered in Azure
Attempt sign-in with a personal Microsoft account (Outlook/ Hotmail/Live)
Consent screen appears and is approved successfully
Redirected back to the app's callback URL with the error above
Additional context - what we ruled out first
Before concluding this was Supabase-side, we independently verified, starting from a completely fresh Azure app registration:
client_id and redirect_uri in the actual outgoing authorize request match the registered app exactly (inspected the literal request URL)
signInAudience confirmed as PersonalMicrosoftAccount at the raw Manifest JSON level, not just the Authentication page's summary UI
Tried both leaving Azure Tenant URL blank (defaults to /common, which rejects personal accounts outright with "You can't sign in here with a personal account") and setting it explicitly to /consumers (accepted by Microsoft, then fails at this callback step) - the failure is specific to the /consumers path, after Microsoft's side has already succeeded
Given #1274 shows a similar issuer-mismatch pattern ("ID token issuer ... does not match expected issuer ..."), our suspicion is the callback's token validation is checking the issuer against a hardcoded expected value that doesn't match what Microsoft actually returns for the /consumers endpoint specifically - but we don't have visibility into the Auth service's internals to confirm this beyond what the linked issues already describe.
Expected behavior
Personal Microsoft accounts should be able to complete sign-in via the documented /consumers tenant URL setup, the same as organizational accounts do via /common or /organizations.
Workaround being used in the meantime
Per your recent Custom OAuth/OIDC Providers feature, we're considering adding Microsoft's consumers endpoint as a separate custom: provider (using its own OIDC discovery document) rather than the built-in azure provider, to sidestep this specific code path entirely. Flagging in case that's useful context for isolating where the bug actually lives (built-in azure provider's callback handling specifically, not a general OIDC/JWKS validation issue).
System information
Supabase project: hosted (not self-hosted)
Auth provider: azure (built-in, not custom)
Following Supabase's own documented setup for Azure sign-in with personal Microsoft accounts (Login with Azure docs, "Configure a tenant URL" section: "If your app is registered as Personal Microsoft accounts only for the Supported account types set Microsoft tenant to consumers"), the OAuth flow completes successfully on Microsoft's side - the user reaches the consent screen, approves, and is redirected back with a valid code - but the callback then fails with:
?error=server_error&error_code=unexpected_failure&error_description=Error+getting+user+profile+from+external+provider
This is the same symptom described in #1549 (title: "Error getting user email from external provider only with public Azure /consumers/ tenant"), which appears to have gone unresolved.
To Reproduce
Register an Azure AD app with Supported account types = "Personal Microsoft accounts only" (signInAudience: PersonalMicrosoftAccount, confirmed via the raw app Manifest, not just the portal UI summary)
In Supabase's Azure provider settings, set Azure Tenant URL to https://login.microsoftonline.com/consumers (exactly as documented)
Client ID/Secret entered correctly, redirect URI matches exactly what's registered in Azure
Attempt sign-in with a personal Microsoft account (Outlook/ Hotmail/Live)
Consent screen appears and is approved successfully
Redirected back to the app's callback URL with the error above
Additional context - what we ruled out first
Before concluding this was Supabase-side, we independently verified, starting from a completely fresh Azure app registration:
client_id and redirect_uri in the actual outgoing authorize request match the registered app exactly (inspected the literal request URL)
signInAudience confirmed as PersonalMicrosoftAccount at the raw Manifest JSON level, not just the Authentication page's summary UI
Tried both leaving Azure Tenant URL blank (defaults to /common, which rejects personal accounts outright with "You can't sign in here with a personal account") and setting it explicitly to /consumers (accepted by Microsoft, then fails at this callback step) - the failure is specific to the /consumers path, after Microsoft's side has already succeeded
Given #1274 shows a similar issuer-mismatch pattern ("ID token issuer ... does not match expected issuer ..."), our suspicion is the callback's token validation is checking the issuer against a hardcoded expected value that doesn't match what Microsoft actually returns for the /consumers endpoint specifically - but we don't have visibility into the Auth service's internals to confirm this beyond what the linked issues already describe.
Expected behavior
Personal Microsoft accounts should be able to complete sign-in via the documented /consumers tenant URL setup, the same as organizational accounts do via /common or /organizations.
Workaround being used in the meantime
Per your recent Custom OAuth/OIDC Providers feature, we're considering adding Microsoft's consumers endpoint as a separate custom: provider (using its own OIDC discovery document) rather than the built-in azure provider, to sidestep this specific code path entirely. Flagging in case that's useful context for isolating where the bug actually lives (built-in azure provider's callback handling specifically, not a general OIDC/JWKS validation issue).
System information
Supabase project: hosted (not self-hosted)
Auth provider: azure (built-in, not custom)