Entra application SSO
Purpose: let users sign into CloudBeaver or Team Edition using their Microsoft Entra identity instead of a separate local application password. Edition support is listed in Entra Product Support.
Standalone DBeaver Lite/Enterprise/Ultimate do not have this server application-login boundary. Their Entra integration is primarily for database and Azure resource authentication.
Supported features
| Feature | What it means |
|---|---|
| Native Entra identity provider | Configure tenant ID, application/client ID, client secret, and the application redirect URL |
| OpenID Connect sign-in | Users select the configured federated login provider and authenticate with Microsoft |
| Profile information | Optional given_name and family_name claims allow display of the user's first and last name |
| Group information | Provider settings can request/read Entra group information for access mapping |
| Additional scopes | Custom scopes can be configured; permissions and required consent must exist in Entra |
| Database-provider integration | Provider settings can enable use of the Entra configuration for database authorization; this still needs a compatible database |
| Microsoft My Apps entry point | Documentation covers a separate sign-on link configuration for users launching the application from My Apps |
The native Entra provider uses OIDC. A generic SAML integration is a different configuration; do not assume it exposes the same JWT/session credentials for downstream integrations.
Configuration responsibilities
Entra administrator: register/configure the application, establish tenant and user-assignment rules, configure redirect URIs, grant the required API permissions/consent, and manage client-credential expiry.
DBeaver administrator: enable Microsoft Entra ID under server authentication settings, create the identity-provider configuration, register its generated redirect link in Entra, and define the required application access mappings.
The Entra registration's client secret authenticates the application. It is not the user's password and does not mean database connections automatically run as a service principal. Database identity depends on the selected database authentication mode.
MFA and Conditional Access
- Entra can require MFA and apply sign-in policies such as device or location restrictions where the tenant configuration, flow, and licensing support them.
- These policies are enforced by Microsoft Entra, not supplied by a DBeaver license. Conditional Access generally requires Entra ID P1; risk-based policies require additional licensing.
- DBeaver documents a Provide access to databases from Azure Cloud provider option associated with Azure access/MFA. Selecting it does not create an MFA policy: Entra policies must already be configured and the actual sign-in must be tested.
- User-interactive MFA is not a property of an unattended client-secret/certificate flow. Do not describe service-principal authentication as “the user's MFA login.”
What SSO does not grant
A successful Entra login does not automatically grant application administration, access to every connection/project, Azure resource permissions, database privileges, or HashiCorp Vault secret access.
Use Entra Groups and User Provisioning for application access, Entra Database Authentication for database authorization, and Vault JWT Workflow for the separate Vault exchange.
Application sessions and downstream tokens have separate lifetimes. Disabling a user in Entra or signing out must not be assumed to immediately terminate every existing application or database session.
Sources
- CloudBeaver Entra provider settings, OIDC, MFA option, and My Apps
- Team Edition Entra provider settings
- Microsoft Conditional Access and license requirements
Related: Entra Integration