Entra database authentication
Purpose: authenticate a database connection using Microsoft Entra credentials instead of a stored database password, where the database service and driver support it.
This is independent of Entra Application SSO. A user can sign into the application with Entra yet connect to a database with a conventional password. Conversely, standalone DBeaver can authenticate a database through Entra without a server application login.
Documented desktop authentication modes
These modes are documented for DBeaver Lite/Enterprise/Ultimate and Team Edition desktop. Availability still depends on the selected database/driver.
| Mode | Identity and use | Advantages and limits |
|---|---|---|
| Enterprise application | Interactive user sign-in with the configured client ID and tenant ID | Documented as user sign-in without storing a client secret in DBeaver; suited to individual access |
| Default credentials | Azure SDK credential chain selects an available identity | Can use environment credentials or Azure managed identity where available; verify which identity actually wins |
| Client secret | Application/service identity authenticates with tenant ID, client ID, and secret | Useful for service connections; secret must be protected and rotated; not individual user identity |
| Client certificate | Application identity authenticates using its certificate/private key | Avoids a client secret, but still requires private-key protection and certificate renewal |
Default credentials is not synonymous with passwordless or per-user. Its selected identity can be an application configured through environment variables or a managed identity. Managed identity requires an appropriate Azure runtime; it is not automatically available on an ordinary workstation.
Web authentication and pass-through
CloudBeaver and Team Edition web document Entra SSO-based database access and client-credential configurations. Both guides require an active Entra session for their Entra connection integration and provide an Authenticate action or direct federated sign-in. Confirm the selected mode's session requirements rather than assuming desktop behavior.
Pass-through documentation describes signing in once with the federated provider, then accessing supported Azure databases without entering another set of credentials. This reuses the compatible session/credentials; it is not a promise that the same raw token can be forwarded to any resource.
The database must accept a token intended for that resource, the Entra identity must exist/be mapped appropriately in the database, and database privileges must be granted. A local application session alone does not supply those Entra credentials.
Database support is target-specific
- Azure SQL / Microsoft SQL Server and Azure Database for PostgreSQL are relevant targets to evaluate; DBeaver documents PostgreSQL group-based Entra access explicitly.
- DBeaver's Azure Cloud Explorer also lists MySQL and Cosmos DB variants, but discovery support is not proof that every service/driver accepts every Entra database-authentication mode.
- Desktop documentation includes Microsoft Entra ID OAuth2 for AWS Redshift through its federated-authorization plugin. Entra is therefore not limited to Azure, but this is a separate database-specific configuration.
- A local/on-premises database is not automatically Entra-enabled because DBeaver supports Entra. Verify that database's server-side identity integration; otherwise a separate pattern such as Entra identity → Vault → database credentials may be needed.
For a proposal, record the exact service, engine/version, JDBC driver/version, authentication mode, user versus service identity, and database grants. A database-family name alone is not a sufficient support statement.
Identity and security boundaries
- An interactive user token can support individual database identity when the database is configured accordingly.
- Client-secret/certificate connections act as the configured application identity, not necessarily the human using DBeaver.
- A group-based connection may use a database-specific group name; this is distinct from application team mapping.
- Entra sign-in, token refresh, and established database sessions have different lifetimes. Test reconnect, expiry, account/group removal, and required session termination.
- Leave Use legacy token permissions disabled unless the database administrator specifically requires it for compatibility.
Sources
- Desktop authentication modes, PostgreSQL groups, and Redshift OAuth2
- Team Edition desktop authentication modes
- CloudBeaver database authentication and session requirements
- Team Edition web database authentication and session requirements
- CloudBeaver pass-through authentication
- Team Edition pass-through authentication
- Microsoft access tokens and resource-specific audiences
Related: Entra Integration · Entra Product Support · Entra Azure Resource Access