feat(auth): add Microsoft Entra ID support with On-Behalf-Of token exchange

[nader-ziada]

Add support for Microsoft Entra ID (Azure AD) as an OIDC provider

Changes:

• Add entra-obo token exchange strategy for On-Behalf-Of flow
• Implement well-known endpoint fallback for providers without oauth-authorization-server (falls back to openid-configuration)
• Add a new config option cluster_auth_mode that has two values: passthrough and kubeconfig
  • Add auto-detection: passthrough when require_oauth=true, else kubeconfig
  • Passthrough mode now automatically exchanges tokens if configured

[Cali0707]

Thanks for all the hard work getting entra id to work @nader-ziada !

I did a first pass looking through the PR, left some comments/questions

[matzew]

Positives:

• Well-structured config validation in ValidateClusterAuthMode() that catches contradictory settings early (passthrough without OAuth, kubeconfig with token exchange, token exchange without OAuth) — all rejected at startup.
• Good test coverage: TokenExchangeRoutingSuite covers auto-detect, explicit modes, and token behavior. Assertion tests verify SHA-256 headers, lifetime defaults, and caching. TestMetadataGenerationFallback covers the core 404-fallback path.
• The trust_proxy_headers default-off approach is the right security posture.
• ResolveClusterAuthMode() with auto-detect is clean and predictable — explicit config wins, otherwise derived from require_oauth.
• oauth.State with atomic.Pointer[Snapshot] gives lock-free concurrent reads with snapshot diffing to detect what changed on SIGHUP reload.
• The 503-line ENTRA_ID_SETUP.md is thorough — covers three deployment patterns (basic, ServiceAccount, OBO), troubleshooting, architecture diagram, and the two-app-registration scenario.
• All 6 review comments from @Cali0707 have been addressed in the force-pushed commit (SHA-256 migration, trust_proxy_headers, STS deduplication, HTTPClient mutex, error messages, centralized auth mode).

Minor observations (non-blocking):

1. OIDC config cache in fetchOpenIDConfiguration uses RLock/check/RUnlock then fetch then Lock/write/Unlock. Two concurrent cache misses will both fetch and write. Functionally harmless (same data, last write wins) but worth being aware of under load.
2. stsConfig parameter threading through ExchangeTokenInContext — the "pass nil to build fresh" pattern pushes caching responsibility to callers. Works fine with the mutex + URL check in tokenExchangingProvider, just an unusual API surface.
3. 2500+ lines across 35 files is a larger PR — just noting for awareness.

[manusa]

Hey @nader-ziada, thanks for the great work on this. The security posture throughout (fail-closed on token exchange failure, opt-in trust_proxy_headers, path-traversal guards) is spot on.

One optional cleanup if you feel like it: IsRequireOAuth() looks like dead code now. After moving Derived() over to ResolveClusterAuthMode(), I couldn't find any remaining callers.

• Interface: pkg/api/config.go:24
• Impl: pkg/config/config.go:394

$ grep -rn 'IsRequireOAuth()'
pkg/api/config.go:24:    IsRequireOAuth() bool
pkg/config/config.go:394:func (c *StaticConfig) IsRequireOAuth() bool {

The RequireOAuth field and require_oauth TOML key are obviously still needed, only the method. Feel free to drop it in this PR or leave it for a follow-up, whichever you prefer.

Thanks again!

[Cali0707]

LGTM, thanks @nader-ziada !!