Inbound OAuth¶

Inbound OAuth allows user authentication to the DataRobot API using access tokens from an identity provider (IdP). This identity federation pattern builds on OAuth 2.0 token exchange (RFC 8693). Instead of issuing DataRobot API keys, configure DataRobot to trust tokens that your IdP (e.g. Okta, Microsoft Entra ID, Ping, or Auth0) already issues. A caller exchanges an IdP access token for a temporary DataRobot access token, and then sends that token as a bearer token on DataRobot API requests.

With this "bring your own IdP" model, users authenticate to the DataRobot API with their existing credentials. Administrators configure the trusted IdP, optional just-in-time (JIT) user provisioning, and how IdP groups, scopes, and organizations map to DataRobot.

How it works¶

Inbound OAuth adds a token exchange step when authenticating to the DataRobot API. Your IdP remains the source of truth for identity; DataRobot validates the IdP token, resolves it to a DataRobot user, and issues its own temporary access token for the API.

sequenceDiagram
    participant Client as User
    participant IdP as Your IdP
    participant DR as DataRobot token exchange
    participant API as DataRobot API
    Client->>IdP: Sign in
    IdP-->>Client: IdP access token
    Client->>DR: Exchange IdP token (RFC 8693)
    DR->>IdP: Fetch JWKS keys and validate token
    DR->>DR: Resolve user (JIT provision if new) and map groups
    DR-->>Client: DataRobot access token
    Client->>API: Request with Bearer DataRobot token
    API-->>Client: Response

• Token exchange—DataRobot validates the IdP token against the keys published at the IdP's JWKS URI, confirms it carries the required dr.impersonation scope, then issues a DataRobot access token that is accepted by DataRobot API endpoints. The token exchange follows RFC 8693.
• JIT user provisioning—when a valid token arrives for a user who does not yet exist in DataRobot, DataRobot can create the account automatically from the token claims. See User provisioning.
• Group mapping—groups in the IdP token map to DataRobot groups, which control the user's access to resources such as AI agents. See Mapping reference.

Prerequisites¶

You must meet the following prerequisites before configuring inbound OAuth:

• SAML single sign-on is enabled for your organization, or enhanced global SAML SSO is enabled for your cluster. Inbound OAuth requires SAML SSO and isn't available to organizations that authenticate users only through LDAP or DataRobot username and password login.
• Inbound OAuth is enabled for your organization or cluster.
• You have the Organization or System Administrator role. The administrator is responsible for configuring inbound OAuth.
• You have an IdP (e.g. Okta, Microsoft Entra ID, Ping, or Auth0) that issues OAuth 2.0 access tokens and publishes a JWKS URI.
• Your IdP can issue access tokens for DataRobot with two required properties: the dr.impersonation scope, and an audience (aud) that matches the value DataRobot shows in OAuth Details. DataRobot validates both on every token; a missing scope denies user access, and a mismatched audience is rejected as invalid_target. See OAuth details and Scope mapping.
• You know the IdP issuer URL and jwksUri, and the claim names the IdP uses for usernames, groups, and scopes.

Contact your DataRobot representative to enable inbound OAuth and, if necessary, to set up the first administrator.

Configuration scope¶

Inbound OAuth supports two configuration scopes; however, only one scope can be active at a time.

Configure inbound OAuth¶

To configure inbound OAuth in DataRobot, navigate to Admin settings > External Application. System administrators must first select an organization to access this page. The path entered here depends on the configuration scope:

This table lists the settings found on the configuration page:

OAuth details¶

The OAuth Details section shows read-only values that DataRobot generates for the configuration. Share them with your developers, who set them in the token-exchange client. See the developer workflow for how each value is used.

External IdP configuration¶

In the External IdP Configuration section, identify the IdP that DataRobot trusts and where it fetches the signing keys used to validate incoming tokens.

Configure your identity provider¶

Set up your IdP so the access tokens it issues meet DataRobot's requirements: the token's issuer matches the External issuer you enter above, its audience (aud) matches the value in OAuth Details, and it carries the dr.impersonation scope. The steps differ by provider.

User provisioning¶

In the User provisioning section, choose whether DataRobot creates accounts automatically.

When inbound OAuth provisions a user, DataRobot:

• Extracts the username and, if mapped, the display name, first name, last name, email, and groups from the token claims.
• Creates and activates the DataRobot account, assigning a non-builder seat if one is available.
• Adds the user to the mapped DataRobot groups.

Configure via the API¶

You can manage inbound OAuth configurations programmatically instead of through the UI, which is useful for automation and infrastructure-as-code. Use the externalApplicationConfigurations endpoint with a personal or application API key that has administrator permissions.

The following request creates an organization-level configuration:

curl --location -X POST \
  "${DATAROBOT_ENDPOINT}/externalApplicationConfigurations/ORGANIZATION_ID/" \
  --header "Authorization: Bearer ${DATAROBOT_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "isEnabled": true,
    "issuer": "https://customer.okta.com/oauth2/default",
    "jwksUri": "https://customer.okta.com/oauth2/default/v1/keys",
    "autoGenerateUsers": true,
    "groupDelimiter": ",",
    "scopeDelimiter": ",",
    "attributesMapping": {
      "username": "preferred_username",
      "firstName": "given_name",
      "lastName": "family_name",
      "email": "email",
      "groups": "groups",
      "scopes": "scope"
    },
    "groupMapping": {
      "idp-group-name": "682d0a4b857826ab7c447136"
    },
    "advancedConfiguration": {
      "jwksRefreshIntervalSeconds": 3600
    }
  }'

The following table describes the configuration options:

Mapping reference¶

Mapping tells DataRobot how to translate the claims in an IdP token into DataRobot users, groups, scopes, and organizations. The model is the same one used for SAML SSO.

Attribute mapping¶

On the Attributes tab, set the claim name DataRobot reads for each user attribute. Because DataRobot and your IdP may use different names, this tab maps the IdP claim to the DataRobot field. The username claim is required; the others are optional. Set the group and scope claim names on the Groups and Scopes tabs.

Group mapping¶

Group mapping is optional. Use it to control which resources (such as AI agents) a user can access by mapping IdP groups to existing DataRobot groups. You can map by DataRobot group ID to IdP group ID or to IdP group name, the same approach used for SAML SSO. Each mapping consists of a DataRobot group paired with an IdP group.

Scope mapping¶

Scope mapping is required for user token exchange. DataRobot validates that each incoming token carries the dr.impersonation scope before it grants access, so you must map the claim DataRobot reads scopes from (typically scp or scope), and your IdP must include dr.impersonation in the tokens it issues. If a user's token doesn't carry dr.impersonation, DataRobot rejects the exchange and the user gets no access.

Organization mapping¶

Organization mapping is only available for global configurations, and is optional. It maps IdP organizations to existing DataRobot organizations, the same way global SAML SSO does. If a token has no mapped organization, or the user belongs to no organization, DataRobot assigns the user to the default organization from System Configuration. Each mapping consists of a DataRobot organization paired with an IdP organization.

For a global configuration, you can also define separate group mapping per organization, so each organization keeps its own group mapping.

Advanced options¶

The following options tune JWKS caching and token validation. Availability depends on your platform, as shown in the Platforms column.

• JWKS refresh interval—set per configuration in Admin settings (the Advanced Options section) or through the config API. Available on all platforms.
• Cluster configuration options—apply to the whole application, not a single configuration. On the Self-Managed AI Platform, your system administrator sets them. On SaaS, DataRobot manages them; contact DataRobot Support to request a change.

Audit logs¶

Inbound OAuth records the following events in the User Activity Monitor:

FAQ¶

How do I let users authenticate to the DataRobot API with Okta, Microsoft Entra ID, or my own IdP?¶

Configure inbound OAuth to trust your IdP, then have developers exchange their IdP token for a DataRobot access token. See Configure inbound OAuth for the admin setup and the developer workflow for the token-exchange steps.

What's the difference between inbound OAuth and SSO?¶

SAML SSO authenticates users to the DataRobot web application in the browser. Inbound OAuth authenticates users to the DataRobot API by exchanging an IdP access token for a DataRobot token. The two are complementary, and SAML SSO is a prerequisite for inbound OAuth, because both rely on your organization federating identity through an external IdP.

Do provisioned users consume a seat?¶

A JIT-provisioned user is assigned a non-builder seat if one is available. If none is available, the account is still created without a seat.

Related¶

• Authenticate to the DataRobot API with inbound OAuth—the developer token-exchange workflow.
• SAML single sign-on—browser-based user authentication.
• SCIM provisioning—automated user lifecycle management.
• Role-based access control (RBAC)—roles and privileges.