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:
- DAB reads the user token from
Authorization: Bearer <user token>
- Uses MSAL.NET
AcquireTokenOnBehalfOf(...) to exchange it for an Azure SQL scope token (https://database.windows.net/.default)
- 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:
- SFI (Secure Future Initiative) compliance — Using secrets for Entra Apps is blocked on most Microsoft tenants and requires multiple levels of exception processes.
- 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
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_recordsboth succeed).The current OBO flow:
Authorization: Bearer <user token>AcquireTokenOnBehalfOf(...)to exchange it for an Azure SQL scope token (https://database.windows.net/.default)SqlConnection.AccessTokenThis requires three environment variables today:
DAB_OBO_CLIENT_IDDAB_OBO_TENANT_IDDAB_OBO_CLIENT_SECRETProblem
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:
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:
WithCertificate(...))WithClientAssertion(...))References