Support Azure national clouds in FAB Azure AD id_token validation

[hussein-awala]

Support Azure national clouds in the FAB auth manager's Azure AD id_token validation.

Why

Before #71735, _decode_and_validate_azure_jwt verified the signature and called
claims.validate() with no issuer check, so any Azure cloud worked. #71735 added issuer
pinning built around a hard-coded login.microsoftonline.com, which means deployments on
Azure Government (login.microsoftonline.us) or Azure operated by 21Vianet
(login.partner.microsoftonline.cn) can no longer authenticate at all: the tenant cannot be
derived from their endpoints, so validation raises before a token is ever examined.

There is a second, older problem in the same path. _get_microsoft_jwks fetches keys from
MICROSOFT_KEY_SET_URL, the commercial cloud's common key set. National clouds sign with
their own keys, so even with the issuer fixed, signature verification would fail.

apache-airflow-providers-fab was excluded from the 2026-08-18 provider wave over the
tenant-canonicalisation regression fixed in #71920; this is the remaining issue from the same
change, and it should land before 3.8.1 ships.

What this does

Rather than hard-coding each cloud's issuer and key set — values that are easy to get subtly
wrong — the acceptable issuers and the jwks_uri are read from the tenant's own OpenID
discovery metadata:

• an allowlist of Microsoft authority hosts (commercial, US Gov, 21Vianet) replaces the single
  hard-coded host when deriving the tenant from configured endpoints;
• for a national cloud, the v2.0 and v1.0 discovery documents supply the accepted iss values
  and the jwks_uri, cached per (authority host, tenant);
• the commercial path is unchanged, including the fast path where a GUID tenant resolves with
  no network call, so existing deployments see no new latency and no behaviour change.

Both the issuer and the jwks_uri are required to live on the configured authority host, so a
tampered discovery document cannot point verification at another host. Every failure path
raises AzureTenantResolutionError; if the v1.0 document cannot be read, the v1.0 issuer is
simply not accepted, which denies a login rather than widening what is trusted. Failures are
not cached.

Azure AD B2C is deliberately out of scope: its authority is per-tenant
(<tenant>.b2clogin.com) and its metadata is addressed by policy, which does not fit a
tenant-only lookup. That is now stated in the docs rather than left to be discovered.

Tests

Nine tests: end-to-end validation on both national clouds asserting the key set comes from the
tenant's metadata; a negative test that a commercial-issued token is rejected for a national
cloud tenant; fail-closed cases for an issuer or jwks_uri pointing off the configured
authority and for missing fields; a v1.0-document-unavailable case; caching; and authority
host derivation including the fallback to commercial.

related: #71735, #71920

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[aaron-y-chen]

Nice, thanks!