SQL MCP Server OBO Authentication in DAB 2.0
We've been watching the rapid adoption of Anthropic’s Model Context Protocol (MCP) closely. While connecting LLM agents to operational data is getting easier, securing that data pipeline is still a massive headache. If an AI agent mutates a production table based on a natural language prompt, standard connections log the service account or application identity. You have no idea which human actually initiated the action. Data API builder (DAB) 2.0 changes this completely by introducing On-Behalf-Of (OBO) authentication support for the SQL MCP Server.
News Summary
Microsoft has rolled out Data API builder (DAB) 2.0, introducing native On-Behalf-Of (OBO) pass-through authentication support for SQL MCP Servers. Handled via Microsoft Entra ID, this update solves a major security flaw in enterprise AI applications: the lack of user accountability in automated data access pipelines.
Previously, developers had to rely on database usernames and passwords or Managed Identities (MI). While Managed Identities successfully eliminated hardcoded passwords, both methods suffer from the same architectural limitation. They log the application or the MCP server itself as the operator inside Azure SQL audit logs.
DAB 2.0 addresses this by enforcing token-based pass-through authentication. When an end-user signs into a client application using Microsoft Entra ID, the application forwards that user's bearer token directly to the MCP server. The runtime then exchanges this incoming token for a downstream Azure SQL access token scoped tightly to that specific individual.
This token injection happens seamlessly at the data-source tier whenever DAB initializes a new database connection. Because connection properties are dynamically built per user, DAB 2.0 includes strict validation checks. It explicitly blocks you from enabling response caching alongside user-delegated authentication to prevent data leaks.
Furthermore, this release allows a unified configuration file to simultaneously expose REST, GraphQL, and MCP endpoints. This unified setup means the same entity permissions, validation schemas, and OBO access rules apply equally across standard web APIs and LLM tool-calling interfaces.
Developer Impact
What this means for developers is a massive reduction in boilerplate security code when building AI-driven SaaS or internal enterprise tooling. If you are constructing an AI agent that runs structured queries or updates tables via tool calls, you no longer need to write custom middle-tier routing logic to track user permissions down to the database level.
By offloading the token exchange to the DAB runtime, your underlying Azure SQL database authenticates the actual calling user, not the proxy agent. If an agent calls a database tool, the resulting SQL audit trails capture the real user's principal name, the exact T-SQL statement executed, and the middle-tier application ID.
This framework drastically reduces security review friction. You can confidently build browser-based tools, LLM apps, or interactive dashboards knowing that database-level Row-Level Security (RLS) and standard Entra permissions automatically apply to the agent's database session without custom backend overrides.
Our Analysis
Our take on this update is overwhelmingly positive for developers building in the AI ecosystem. For a long time, the rush to deploy agentic workflows meant cutting corners on compliance and security. By integrating OBO into an MCP server runtime, Microsoft is making enterprise-grade security a default configuration rather than a complex engineering hurdle.
The biggest win here is the choice to leverage the open-source Model Context Protocol. Instead of locking developers into a proprietary ecosystem, DAB 2.0 acts as a clean, standardized bridge between client-side LLMs and Azure SQL. We predict this architecture will become the blueprint for enterprise data connectors over the next year. Competitors offering static vector or database bridges will be forced to implement similar pass-through token systems to stay viable in production environments.
The architectural decision to make response caching and user-delegated auth mutually exclusive is also a smart move. While some devs might complain about the performance overhead of per-user token translation, caching user-specific SQL queries at the gateway level is an absolute recipe for accidental data exposure.
Ultimately, this moves the needle forward for indie hackers and enterprise teams alike. It proves that the tool-calling ecosystem is maturing past simple hobby projects and evolving into production-ready infrastructure where auditability is a hard requirement.
| Feature / Metric | Username & Password / Managed Identity | OBO Pass-Through (DAB 2.0) |
| Logged Operator | Connection string identity / App identity | Actual authenticated end-user |
| Token Handling | Static credentials or system-assigned tokens | Dynamic exchange via Entra ID |
| Gateway Caching | Supported | Explicitly disabled by validator |
| Audit Granularity | Low (Tracks <i>which</i> service ran the tool) | High (Tracks <i>who</i> instructed the tool) |
The following JSON block shows how to configure your dab-config.json data source to enable user-delegated authentication, along with a minimal client-side snippet verifying the identity pass-through.
{
"data-source": {
"database-type": "mssql",
"connection-string": "@env('MSSQL_CONNECTION_STRING')",
"user-delegated-auth": {
"enabled": true,
"provider": "EntraId",
"database-audience": "https://database.windows.net"
}
}
}// Verifying the identity recognized by Azure SQL via a client call
const headers = await getAuthHeaders(); // Contains user's Entra ID bearer token
const response = await fetch(`${API_URL}/api/WhoAmI`, {
method: "GET",
headers: headers
});
const payload = await response.json();
const sqlUserName = payload.value[0].UserName;
// Logs the actual end-user UPN, confirming the MCP server isn't masking the identity
console.log(`SQL sees this request as: ${sqlUserName}`);FAQs
Q: Does enabling OBO authentication affect database connection pooling performance?
A: Yes, because connections are isolated per user principal to maintain security boundaries, standard global connection pooling is bypassed. DAB 2.0 mitigates this by utilizing a token cache that is safely scoped per individual user session.
Q: Can I keep caching enabled for public tables while using OBO for user data?
A: No. The DAB configuration validator enforces a hard rule where response caching and user-delegated authentication are mutually exclusive within the engine configuration to completely eliminate cross-user data leaks.
Q: What fields are exposed in the database logs to verify this pass-through works?
A: Azure SQL Security Audit logs expose the database_principal_name_s for the user, the statement_s executed, and the obo_middle_tier_app_id_s to trace the specific application proxying the request.
Q: Do I need to modify my database connection strings to pass the user tokens?
A: No. You must use a completely bare connection string that omits user IDs, passwords, or authentication types; the DAB 2.0 engine handles injecting the access token dynamically.
Our Take
Data API builder 2.0 addresses the absolute core of the security challenge plaguing modern agentic AI systems. By embedding On-Behalf-Of authentication directly into the SQL MCP Server pipeline, developers can confidently build tools without worrying about auditing blind spots or complex permission mapping. It bridges the gap between smart, autonomous LLM tool usage and rigid enterprise compliance rules. We will continue tracking the evolution of the Model Context Protocol closely as it cements itself as the standard for developer data integrations.
