Revisit: OIDC ALLOWED_HOSTS hardcoded to *.azure.com blocks sovereign clouds and custom domains

[tnaum-ms]

Context

OIDC authentication for Microsoft Entra ID is configured with a hardcoded ALLOWED_HOSTS list in two places:

• src/documentdb/auth/MicrosoftEntraIDAuthHandler.ts line 46
• src/documentdb/playground/playgroundWorker.ts line 122

Both use:

ALLOWED_HOSTS: ['*.azure.com'],

This blocks OIDC authentication when the cluster hostname is not under *.azure.com, for example:

• Azure sovereign clouds: *.azure.cn (China), *.azure.us (US Gov), *.azure.de (Germany legacy).
• Private endpoints exposed under a customer owned domain.
• Test or staging environments that route through a non Azure DNS.

Failure surfaces as a generic connection error from the driver, with no hint that the cause is the OIDC allow list.

Suggested solutions

1. Build the allow list from the hostname of the connection string when the auth mechanism is Entra ID, narrowing it to the actual target rather than a wildcard.
2. Accept a user setting (documentDB.auth.entraId.allowedHosts) for advanced users with custom or sovereign deployments.
3. When the OIDC driver rejects the host, surface a clearer error with a link to documentation explaining the limitation.

Definition of done

• Entra ID authentication works against sovereign cloud hostnames.
• The two ALLOWED_HOSTS literals are derived from a shared helper so they cannot drift apart again.

[tnaum-ms]

During review of PR #721 (the fix for this issue), the initial implementation approach turned out to be insecure and was replaced during review.

The issue suggested solution 1: build ALLOWED_HOSTS from the hostname of the connection string. A first implementation did exactly that -- it used *.${host} as the pattern. Review caught two problems with this:

1. Security. ALLOWED_HOSTS is a security control: the MongoDB driver only sends the OIDC token to a server whose hostname matches one of the patterns. Building the pattern directly from the connection string lets an attacker-supplied hostname widen its own allowlist. For example, a connection string pointing at evil.com would produce *.evil.com and self-authorize. This defeats the purpose of the control.

2. Correctness. Connection string hostnames can include a port (e.g., cluster.azure.com:10255). The pattern *.cluster.azure.com:10255 does not match under the driver's endsWith matching, so authentication would fail even for legitimate Azure hosts.

What was shipped instead: a hostname classifier that extracts the Azure-family registrable suffix and returns *.azure.<tld>:

• *.azure.com for public cloud
• *.azure.us and *.azure.cn for sovereign clouds
• Lookalikes such as node.azure.com.evil.com are rejected (the azure label must be the registrable second level)
• Anything not positively classified as Azure falls back to the safe ['*.azure.com']

Truly custom (non-Azure) domains are intentionally NOT auto-trusted -- supporting them safely requires an explicit opt-in user setting and is tracked as a separate follow-up.

Solution 2 (user setting for advanced/sovereign deployments) from the issue description is still open as follow-up work. The sovereign-cloud Entra token endpoint divergence is also a separate open item not addressed in this PR.