OIDC discovery hardcodes http:// in issuer when served over HTTPS, breaking azapi/MSAL auth

[sfy247]

Summary

When TLS is enabled, /{tenant}/v2.0/.well-known/openid-configuration still reports http:// URLs for issuer, token_endpoint and jwks_uri, even when the document is fetched over HTTPS. The ARM metadata endpoint on the same host does adapt to the request scheme, so the two disagree.

This makes the emulator unusable with any MSAL-based client — notably the azapi Terraform provider, which every Azure Verified Module uses.

Reproduce

floci/floci-az:0.11.0, started with FLOCI_AZ_TLS_ENABLED=true.

T=00000000-0000-0000-0000-000000000002

curl -sk "https://localhost:4577/$T/v2.0/.well-known/openid-configuration" | jq '.issuer, .token_endpoint'

"http://localhost:4577/00000000-0000-0000-0000-000000000002/v2.0"
"http://localhost:4577/00000000-0000-0000-0000-000000000002/oauth2/v2.0/token"

For contrast, the ARM metadata endpoint on the same host over the same scheme is correct:

curl -sk "https://localhost:4577/metadata/endpoints?api-version=2022-09-01" | jq '.resourceManager, .authentication.loginEndpoint'

"https://localhost:4577"
"https://localhost:4577/"

Expected

When the request arrives over HTTPS, the discovery document should report https:// URLs — matching the behaviour /metadata/endpoints already has.

Impact

azapi cannot authenticate, and there is no configuration that works:

• ARM_ACTIVE_DIRECTORY_AUTHORITY_HOST=https://localhost:4577/ →

  ClientSecretCredential: unable to resolve an endpoint: ResolveEndpoints():
  TenantDiscoveryResponse: issuer 'http://localhost:4577/<tenant>/v2.0' does not
  match authority 'https://localhost:4577/<tenant>/' or any trusted/alias rule
  

• ARM_ACTIVE_DIRECTORY_AUTHORITY_HOST=http://localhost:4577/ → azidentity silently drops ClientSecretCredential from the chain, since it requires an HTTPS authority. The chain then falls through to AzureCLICredential.

ARM_DISABLE_INSTANCE_DISCOVERY=true does not help, as the failure is issuer validation rather than instance discovery.

The azurerm provider is unaffected, because it authenticates via /metadata/endpoints. So azurerm-based configurations work fine and azapi-based ones cannot run at all — which rules out the entire AVM module ecosystem.

Suggested fix

Derive the scheme in the OIDC discovery response from the incoming request (or from FLOCI_AZ_TLS_ENABLED), the same way /metadata/endpoints already does. issuer, token_endpoint, jwks_uri, authorization_endpoint and end_session_endpoint all appear to be affected.

Environment

Image	floci/floci-az:0.11.0
TLS	FLOCI_AZ_TLS_ENABLED=true
Client	Azure/azapi v2.12.0 via OpenTofu 1.12.6
Host	Ubuntu 24.04

Thanks for Floci — the azurerm path has been working well for us, this is the one thing blocking the AVM modules.

[github-actions]

👋 Thanks for opening your first issue in floci-az!

A maintainer will triage this and add the right service label. If you included a minimal reproduction and the floci-az version, that is everything we need — no action required from you right now.

Come say hi in Slack if you want to talk it through with maintainers and other contributors. Questions about Azure behaviour, design tradeoffs, and rough proposals are all welcome there.