External authentication, SSO and MFA

Purpose and authority

Preferences → Authentication configures supported external sign-in providers. Management of this global configuration requires the authorized Platform Administrator role. A role that can inspect ordinary Preferences does not automatically have authority to save provider settings, replace secrets or test global authentication.

SSO establishes identity, role assignments control authorization, and MFA completes the account's required verification. Enabling an external provider does not grant administrative access or remove MFA. Prepare an authorized recovery route and a laboratory identity before changing an integration.

Configure an external provider

1. Open Preferences → Authentication and select the intended provider's card.
2. Prepare an approved application in the provider's administration system.
3. Copy Dova's read-only Authorized callback URL and register that exact address with the provider.
4. Enter Client ID and the provider-specific configuration. Microsoft uses Tenant ID; Okta and Auth0 use Issuer URL; GitLab can use its supported issuer for the intended service.
5. Use Replace client secret only when replacing the stored secret is necessary. Leaving it blank preserves the current value according to the form's guidance.
6. Set the provider's enabled state and choose its corresponding save action, such as Save Google or Save Microsoft.
7. Confirm persistence, then use Test discovery or Test provider as displayed. The test uses the saved configuration, not unsaved fields.
8. Perform a fresh sign-in with the authorized laboratory identity and verify the final workspace and role.

The supported cards are Google, Microsoft, Okta, Auth0, GitHub and GitLab. The GitHub card states that a verified primary email must match an active Dova user. Follow each provider's own identity rules rather than applying one provider's onboarding behavior to all six.

Registration policy

Allow self-registration has a separate Save registration policy action. Review the current onboarding policy and the resulting workspace identity when testing it. Enabling this switch does not convert existing accounts, renew trials or assign platform roles. An access refusal caused by account lifecycle should be investigated through the tenant and subscription information.

Complete MFA

At sign-in, follow the Verification or recovery code flow. For first-time factor setup, register the displayed QR or setup key privately in the intended authenticator and submit its current code. Store one-use recovery codes securely. Do not capture the setup key, QR, recovery codes or verification codes for documentation.

Trust this device is an explicit account choice. It does not disable MFA globally. If you selected the wrong identity, use Use another account. If the factor is unavailable, follow the authorized recovery process.

Acceptance and error recovery

Test an authorized identity, an unauthorized identity and an incorrect verification code in a controlled environment. Successful configuration admits only the authorized account into the expected workspace. A provider discovery result alone does not prove complete login success or role authorization.

For failures, inspect callback accuracy, issuer or tenant, enabled state and account correspondence. Separate provider connectivity, MFA failure and permission denial. Avoid repeated secret replacement without identifying the failed stage.

Related guides: Users, Roles and permissions and Tenant lifecycle.