SWA Standard Easy Auth fails with error 9002325 (PKCE required for cross-origin) — all documented config + multiple workarounds exhausted

Severity: X (no documented workaround found)

Issue type: Authentication / Authorization

Body:

Edited Pii Info  

ISSUE SUMMARY

SWA's AAD authentication gate fails on the token redemption step.

Users complete sign-in (credentials + Microsoft Authenticator MFA)

successfully on AAD's side, but the SWA's callback cannot redeem

the authorization code. Entra sign-in logs report error code 9002325:

 

 "Proof Key for Code Exchange is required for cross-origin

  authorization code redemption."

 

After ~5 callback attempts, AAD's loop-breaker fires AADSTS50196

(LoopDetected) and shows the generic "We couldn't sign you in" page.

 

SWA Standard's Easy Auth is a confidential client using a client

secret. It does not generate a PKCE code verifier. AAD appears to

be enforcing cross-origin PKCE rules because the SWA's callback

URI origin differs from the token endpoint origin.

 

CONFIGURATION VERIFIED CORRECT

• SWA SKU: Standard, fully active (upgraded 2026-05-28)
• staticwebapp.config.json: schema-valid, no _comment* or $schema

 properties, no 404 catch-all masking, /.auth/* route exempted

 from /* authenticated catch-all

• App reg Authentication: Web platform redirect URIs

edited PII info

 registered. Single SPA platform entry "http://localhost" for

 local dev. ID tokens checkbox enabled. Access tokens checkbox

 disabled. Allow public client flows: No. ServicePrincipalLock

 Configuration enabled with AllProperties = true (confirmed not

 blocking property updates — we have made several manifest edits

 successfully today).

• App reg signInAudience: AzureADMyOrg
• App reg requestedAccessTokenVersion: tested both 1 and 2 — same

 result (eliminates token version as trigger)

• Client secret: valid (Key Vault reference via SWA system-assigned

 managed identity with Key Vault Secrets User role on

 Steelcraft-Keyvault — sign-in logs confirm no AADSTS7000215)

• Conditional Access: "MFA - SG Tools" policy applied. Grant tab

 only has "Require multifactor authentication" checked. No

 Session restrictions, no Authentication Strength override.

 Tested with policy in both On and Report-only modes — same

 result.

 

CONFIGURATIONS TESTED AND ELIMINATED AS TRIGGERS

• Removed [http://localhost] from SPA platform temporarily — same

 error (eliminates mixed Web+SPA platform as trigger)

• Removed _comment* properties from staticwebapp.config.json
• Removed $schema property from staticwebapp.config.json
• openIdIssuer with /v2.0 suffix + requestedAccessTokenVersion 2 — same error
• openIdIssuer without /v2.0 suffix + requestedAccessTokenVersion 1 — same error

 (proves endpoint version is not the trigger)

• Cross-tenant access settings: nothing PKCE-related
• Entra ID Security Defaults: not enabled (already using CA policies)
• Authentication Methods policies: no phishing-resistant tenant

 requirement

• No additional CA policies that would apply to this sign-in

 

edited PII

  you in" page with error code 9002325

 

CORRELATION IDS FROM RECENT FAILED ATTEMPTS

[Rudy: extract 2-3 most recent from Entra Sign-in logs]

 

QUESTIONS

1. Is SWA Standard's Easy Auth (confidential client using client

  secret) supported with Microsoft Entra's cross-origin PKCE

  enforcement rules introduced in 2024?

2. If yes, what configuration on the app reg, SWA resource, or

  tenant level allows the flow to succeed?

3. If no, is there a known workaround, or is SWA Easy Auth on

  Standard SKU currently broken for new deployments in tenants

  subject to cross-origin PKCE enforcement?

4. As an interim path, can a tenant-level exception be applied

  to app reg 099a81e5-... that exempts it from cross-origin

  PKCE enforcement?

 

ATTACHMENTS AVAILABLE ON REQUEST

• Full app reg manifest JSON (sanitised)
• staticwebapp.config.json (current deployed state)
• Recent Entra sign-in log entries with full request details
• SWA deployment pipeline configuration
• Screenshots of the failing sign-in flow
• Network trace of the SWA→AAD token request (if relevant)