For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.
Docs Menu
Docs Home
/ /
Security
Docs Home
/
Management
/
Ops Manager
/
Security
Docs Home
/
Management
/
Ops Manager
/
Security

OIDC Authentication for Backing Databases

Ops Manager and the Backup Daemon can authenticate to all supported backing databases using OIDC. This includes the Ops Manager Application Database, the snapshot store, the oplog store, and the sync store, including the metadata databases for S3-backed snapshot and oplog stores. OIDC authentication is available in addition to the existing authentication mechanisms that Ops Manager supports. Enabling OIDC for a backing database does not disable or replace any other authentication mechanism that you already configured.

This page describes the OIDC authentication modes that Ops Manager supports for backing databases, the prerequisites for enabling OIDC, and the limitations of this feature. OIDC authentication covered on this page applies only to connections that Ops Manager and the Backup Daemon make to backing databases. It does not cover end-user authentication to Ops Manager itself.

Supported OIDC Modes

Ops Manager supports two OIDC authentication modes for backing databases.

Mode
Description

Custom callback

Use the client credentials flow to request access tokens from any OIDC-compliant IdP, such as Keycloak, Okta, or Azure. This mode requires a client ID and client secret.

Built-in environment authentication

Use a workload identity provided by the deployment environment for Azure, GCP, or Kubernetes. The MongoDB driver obtains a workload identity token from the environment automatically, and this mode does not require a client secret.

Prerequisites

Before you enable OIDC authentication for a backing database, confirm the following prerequisites.

  • The backing database must run MongoDB 7.0.11 or later.

  • MongoDB must be configured to allow the MONGODB-OIDC authentication mechanism and to define oidcIdentityProviders for the IdP that you intend to use.

  • For the custom callback mode, you need an IdP client with the client credentials flow enabled, and the IdP's token and JWKS endpoints must be reachable over HTTPS.

  • For built-in environment authentication, the deployment environment must already provide a valid workload identity for Azure, GCP, or Kubernetes.

  • The Ops Manager server host and the Backup Daemon host must both trust the IdP's TLS certificate in the JVM or OS trust store. If the IdP endpoint uses a private certificate authority or a self-signed certificate, and that certificate is not trusted, Ops Manager and the Backup Daemon fail to acquire tokens with a TLS handshake error.

Limitations

  • Ops Manager exposes OIDC configuration for the Ops Manager Application Database only through conf-mms.properties. The Admin interface does not include a UI for Ops Manager Application Database OIDC configuration.

  • The OIDC authentication described on this page applies only to connections that Ops Manager and the Backup Daemon make to backing databases. It does not apply to end-user authentication to Ops Manager.

Version Validation

Ops Manager validates the target MongoDB version before it applies an OIDC configuration. The validation differs by connection type:

  • For a backing store, creating or updating the store through the Admin interface or the API with a target MongoDB version earlier than 7.0.11 fails.

  • For the Ops Manager Application Database, Ops Manager blocks startup if OIDC is enabled and the Ops Manager Application Database runs a MongoDB version earlier than 7.0.11.

Restart Requirements

Important

Changing Ops Manager Application Database OIDC settings requires restarting Ops Manager. Because the Backup Daemon reads the same conf-mms.properties file at startup, restart the Backup Daemon as well.

Changing OIDC settings for a backing store, such as the snapshot store, oplog store, or sync store, also requires restarting Ops Manager and the Backup Daemon. This matches the existing behavior when you change a backing store's username or password.

Fallback and Rollback

If you need to roll back OIDC authentication for a backing database, use the applicable procedure.

  • For the Ops Manager Application Database, set mms.oidcEnabled to false in conf-mms.properties, restore a non-OIDC authentication mechanism in the connection configuration, and restart Ops Manager and the Backup Daemon.

  • For a backing store, disable OIDC through the Admin interface or the API. If you use the API, submit oidc: {enabled: false} with a non-OIDC authentication configuration for that store, and restart Ops Manager and the Backup Daemon.

Back

Configure OIDC

Next

Secure with Authentication

On this page