Docs Menu
Docs Home
/
MongoDB Manual
/ / / / /

Configure an External Identity Provider

On this page

  • About this Task
  • Before you Begin
  • Steps
  • Next Steps
  • Learn More

To configure Workforce Identity Federation with OIDC, register your OIDC application with an external identity provider, such as Okta or Microsoft Entra ID. This ensures secure authentication and facilitates user management.

Workforce Identity Federation uses OIDC. You can use any external identity provider that supports the OIDC standard.

You can configure your OIDC application for the following grant types:

  • Authorization Code Flow with PKCE

  • Device Authorization Flow

MongoDB recommends that you use Authorization Code Flow with PKCE for increased security. Use Device Authorization Flow only if your users need to access the database from machines with no browser.

Note

Workforce Identity Federation supports only JWT for authentication. It doesn't support opaque access tokens.

The following procedures provide detailed configuration instructions for Microsoft Entra ID and Okta, and generic configuration instructions for other external identity providers.

  • To use Okta as an identity provider, you must have an Okta account.

  • To use Microsoft Entra ID as an identity provider, you must have a Microsoft Azure account.

1
  1. Navigate to App registrations.

    1. In your Azure portal account, search and click Microsoft Entra ID.

    2. In the Manage section of the left navigation, click App registrations.

  2. Click New registration.

  3. Apply the following values.

    Field
    Value

    Name

    MongoDB - Workforce

    Supported Account Types

    Accounts in this organizational directory only (single tenant)

    Redirect URI

    - Public client/native (mobile & desktop)
    - To access clusters using MongoDB Compass and MongoDB Shell, set the Redirect URI to http://localhost:27097/redirect.
  4. Click Register.

To learn more about registering an application, see Azure Documentation.

2
  1. Navigate to Token Configuration.

    In the Manage section of the left navigation, click Token Configuration.

  2. Click Add groups claim.

  3. In the Edit groups claim modal, select Security.

    What groups you select depend on the type of groups you configured in your Azure environment. You may need to select a different type of group to send the appropriate group information.

  4. In the Customize token properties by type section, only select Group ID.

  5. Click Add.

To learn more about adding a group claim, see Azure Documentation.

3
  1. Click Add optional claim.

  2. In the Add optional claim modal, select Access.

  3. Select a claim that carries a user identifier that you can refer to in MongoDB access logs such as an email.

    You can use the UPN claim to identify users with their email address.

  4. Click Add.

  5. In the Microsoft Graph Permissions note, check the box, and click Add.

To learn more, see Azure Documentation.

4
  1. In the Manage section of the left navigation, click Manifest.

  2. Update the accessTokenAcceptedVersion from null to 2.

    The number 2 represents Version 2 of Microsoft's access tokens. Other applications can use this as a signed attestation of the Active Directory-managed user's identity. Version 2 ensures that the token is a JSON Web Token that MongoDB understands.

  3. Click Save.

To learn more about adding an optional claim, see Azure Documentation.

5
  1. In the left navigation, click Overview.

    Copy the Application (client) ID value.

  2. In the top navigation, click Endpoints.

    Copy the OpenID Connect metadata document value without the /.well-known/openid-configuration part.

    You can also get this value by copying the value for issuer in the OpenID Connect metadata document URL.

The following table shows what these Microsoft Entra ID UI values map to in the MongoDB oidcIdentityProviders parameter:

Microsoft Entra ID UI
MongoDB oidcIdentityProviders Parameter Field

Application (client) ID

clientID
audience

OpenID Connect metadata document (without /.well-known/openid-configuration)

issuer

1

In your Okta Admin dashboard, use the left navigation pane to go to Applications → Applications.

  1. On the Applications screen, click Create App Integration.

  2. In the Sign-in method section, select OIDC - OpenID Connect.

  3. In the Application type section, select Native Application.

  4. Click Next.

To learn more, see Create OIDC app Integrations.

2

After you create an app integration, you are automatically redirected to the New Native App Integration screen.

  1. In the App integration name field, enter a name for your application.

  2. In the Grant type field, select grant types.

    Enable the following grant types:

    • Authorization Code or Device Authorization

    • (Optional) Refresh Token

      Enabling refresh tokens provides a better user experience. When refresh tokens are not enabled, users must re-authenticate with the identity provider once their access token expires.

  3. In the Sign-in redirect URIs section, enter a URL.

    Enter the following URL: http://localhost:27097/redirect.

  4. In the Assignments section, configure the Controlled access and Enable immediate access fields.

    1. For the Controlled access field, select Allow everyone in your organization to access.

    2. For Enable immediate access field, ensure Enable immediate access with Federation Broker Mode is checked.

  5. Click Save.

To learn more, see Create OIDC app integrations.

3

On your application dashboard, go to the General tab and configure the following:

  1. In the Client ID field, click the icon to copy the client ID for later use.

  2. In the Proof Key for Code Exchange (PKCE) field, ensure Require PKCE as additional verification is enabled (checked by default).

4

In the left navigation pane, go to Security → API. Click Add Authorization Server.

  1. In the Name field, enter a name for your server.

  2. In the Audience field, paste the client ID from the previous step.

  3. (Optional) In the Description field, enter a description of your server.

  4. Click Save.

To learn more, see Create an Authorization Server.

5

After you create your authorization server, you are automatically redirected to your authorization server's screen.

Under the Settings tab, save the issuer URI by copying the first part of the Metadata URI up to the .well-known section. The URI structure should be similar to: https://trial4238026.okta.com/oauth2/ausabgmhveoOQSMsE697.

6

On your authorization server screen, go to the Claims tab and click Add Claim.

  1. Configure Groups claim with the following configuration information:

    Field
    Value

    Name

    Enter a name for your claim.

    Include in token type

    Click the drop-down and select Access Token.

    Value type

    Click the drop-down and select Groups.

    Filter

    Click the drop-down and select Matches regex. Next to the drop-down, enter .*.

    Disable claim

    Do not check.

    Include in

    Select Any scope.

  2. Click Create.

To learn more, see Create Claims.

7

On your authorization server screen, go to the Access Policies tab and click Add Policy.

  1. In the Name field, enter a policy name.

  2. In the Description field, enter a description for the policy.

  3. In the Assign to field, select All clients.

  4. Click Create Policy.

To learn more, see Create an Access Policy.

8

Under the Access Policies tab, click Add Rule.

  1. In the Rule Name field, enter a name for the access policy.

  2. For IF Grant Type is, select a grant type.

    When configuring grant types, select the appropriate option based on the client behavior:

    • If the client is acting on behalf of itself, select Client Credentials.

    • If the client is acting on behalf of a user, select the following:

      • Authorization Code

      • Device Authorization

  3. Add rule configurations based on your organization's security policy.

    Example Okta rule configuration:

    Field

    Value

    AND user is

    Select Any user assigned to the app.

    AND Scopes requested

    Select Any scopes.

    THEN Use this inline hook

    None (disabled)

    AND Access token lifetime is

    1 Hours

    AND Refresh token lifetime is

    Click the second drop-down and select Unlimited.

    but will expire if not used every

    Enter 7 days.

  4. Click Create Rule.

To learn more, see Create Rules for each Access Policy.

9

In the left navigation pane, go to Directory → Groups and click Add Group.

  1. In the Name field, name your directory OIDC.

  2. (Optional) In the Description field, enter a description for your rule.

  3. Click Save.

To learn more, see Create a Group.

10

In the left navigation pane, go to Directory → People and click Add Person.

  1. Provide user details by entering the following values in the corresponding fields:

    Field
    Value

    User type

    Select User.

    First name

    Provide name as needed.

    Last name

    Provide name as needed.

    Username

    Enter an email as a username.

    Primary email

    Enter an email. The email must be same as the one used for the Username field.

    Secondary email

    Optional.

    Groups

    Enter OIDC.

    Activation

    Select Activate Now and check I will set password.

    Password

    Enter a password.

    User must change password on first login

    Select Optional

  2. Click Save.

To learn more, see Add Users Manually.

1

Select public client/native application as the client type.

2
3

For groups, this step ensures that your access tokens contain the group membership information of the user authenticating. MongoDB uses the values sent in a groups claim for authorization.

4

(Optional) Allow refresh tokens if you want MongoDB clients to refresh the tokens for a better user experience

5

(Optional) Configure the access token lifetime (exp claim) to align with your database connection session time

After you register your application, save the issuer, clientId, and audience values to use in the next stage of the configuration.

Back

Workforce (Humans)