Support secretless credential options (workload identity federation / certificates) for OBO authentication

[kshyju]

Summary

DAB SQL MCP OBO currently only supports client secrets (DAB_OBO_CLIENT_SECRET + WithClientSecret(...)) for building the MSAL confidential client used in the On-Behalf-Of flow. Please add support for secretless credential options such as workload identity federation (FIC), client certificates, or client assertions.

Context

We are validating SQL MCP hosting inside a managed Connector Gateway / ADC sandbox environment. We tested DAB 2.0.1-rc over HTTP MCP and confirmed the basic OBO flow works end-to-end (describe_entities, read_records both succeed).

The current OBO flow:

1. DAB reads the user token from Authorization: Bearer <user token>
2. Uses MSAL.NET AcquireTokenOnBehalfOf(...) to exchange it for an Azure SQL scope token (https://database.windows.net/.default)
3. Sets the token on SqlConnection.AccessToken

This requires three environment variables today:

• DAB_OBO_CLIENT_ID
• DAB_OBO_TENANT_ID
• DAB_OBO_CLIENT_SECRET

Problem

In our managed hosting scenario, the sandbox environment is fully abstracted from the customer. Storing customer app secrets in sandbox/container configuration is problematic because:

1. SFI (Secure Future Initiative) compliance — Using secrets for Entra Apps is blocked on most Microsoft tenants and requires multiple levels of exception processes.
2. Security posture — Long-lived client secrets in container configuration are difficult or unacceptable for many tenants.

OBO still requires the middle-tier app to authenticate as a confidential client, but the credential ideally should not need to be a long-lived client secret.

Requested Credential Options

Support one or more of the following in addition to client secret:

• Workload identity federation (Federated Identity Credentials / FIC)
• Client certificate (WithCertificate(...))
• Client assertion (WithClientAssertion(...))

References

• DAB OBO documentation

[JerryNixon]

This is actually a "fix".