# インバウンドOAuth

> インバウンドOAuth - Configure inbound OAuth so users authenticate to the DataRobot API with access tokens
> from your own identity provider (IdP). An identity-federation pattern built on external OAuth and
> OAuth 2.0 token exchange (RFC 8693), with just-in-time provisioning and group mapping for Okta,
> Microsoft Entra ID, Ping, and Auth0.

This Markdown file sits beside the HTML page at the same path (with a `.md` suffix). It summarizes the topic and lists links for tools and LLM context.

Companion generated at `2026-08-13T14:33:11.000900+00:00` (UTC).

## Primary page

- [インバウンドOAuth](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md): Full documentation for this topic (Markdown sidecar).

## Sections on this page

- [仕組み](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#how-it-works): In-page section heading.
- [前提条件](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#prerequisites): In-page section heading.
- [Configuration scope](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configuration-scope): In-page section heading.
- [Configure inbound OAuth](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configure-inbound-oauth): In-page section heading.
- [OAuth details](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#oauth-details): In-page section heading.
- [External IdP configuration](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#external-idp-configuration): In-page section heading.
- [Configure your identity provider](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configure-your-idp): In-page section heading.
- [ユーザープロビジョニング](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#user-provisioning): In-page section heading.
- [Configure via the API](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configure-via-the-api): In-page section heading.
- [Mapping reference](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#mapping-reference): In-page section heading.
- [Attribute mapping](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#attribute-mapping): In-page section heading.
- [Group mapping](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#group-mapping): In-page section heading.
- [Scope mapping](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#scope-mapping): In-page section heading.
- [Organization mapping](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#organization-mapping): In-page section heading.
- [高度なオプション](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#advanced-options): In-page section heading.
- [Audit logs](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#audit-logs): In-page section heading.
- [FAQ](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#faq): In-page section heading.
- [How do I let users authenticate to the DataRobot API with Okta, Microsoft Entra ID, or my own IdP?](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#authenticate-with-idp): In-page section heading.
- [What's the difference between inbound OAuth and SSO?](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#inbound-oauth-vs-sso): In-page section heading.
- [Do provisioned users consume a seat?](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#provisioned-users-seat): In-page section heading.
- [関連情報](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#related): In-page section heading.

## Documentation content

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](https://datatracker.ietf.org/doc/html/rfc8693)). 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.

> [!NOTE] 備考
> Inbound OAuth handles inbound API authentication: external callers authenticating to DataRobot. It is distinct from outbound OAuth, where DataRobot authenticates to a third-party service on your behalf.

**SaaS:**
> [!NOTE] 本機能の提供について
> Inbound OAuth has no license requirement, but it isn't enabled by default. DataRobot must enable it for your organization through an application configuration. If it isn't enabled, contact your DataRobot representative.
> 
> Required permission: Organization or System Administrator

On the Managed AI Platform, the high-level workflow to configure inbound OAuth for an organization is as follows:

前提条件
を確認して、すべて満たします。
Register a trusted IdP
and optionally, enable
JIT user provisioning
.
Define
mapping
for attributes, groups, and scopes so DataRobot resolves each token to the right user and resources.
Share the
developer workflow
with your API developers.

**セルフマネージド:**
> [!NOTE] 本機能の提供について
> Required permission: System Administrator (global configuration) or Organization Administrator (organization configuration)
> 
> Required cluster configuration: enable exactly one of the following:
> 
> ENABLE_GLOBAL_EXTERNAL_APPLICATION_AUTHENTICATION
> =
> True
> ENABLE_ORGANIZATION_EXTERNAL_APPLICATION_AUTHENTICATION
> =
> True

On the Self-Managed AI Platform, configure inbound OAuth globally (one configuration for the whole application) or per organization. The basic workflow is as follows:

前提条件
を確認して、すべて満たします。
Enable the feature through cluster configuration and choose a
configuration scope
.
Register a trusted IdP
and, optionally, enable
JIT user provisioning
.
Define
mapping
for attributes, groups, scopes, and organizations.
Set
advanced options
for JWKS caching and token validation.


## 仕組み

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 .

## 前提条件

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.

> [!NOTE] 重要
> Inbound OAuth requires SAML single sign-on. Because users provisioned through inbound OAuth authenticate exclusively with external tokens (never a DataRobot password), your organization must already federate identity through an external IdP. Until SAML SSO is enabled, the Enabled toggle on the configuration page remains unavailable and displays the message `Enable SAML SSO for the organization to use this feature` (or `Enable enhanced global SAML SSO to use this feature` for a global configuration). All other fields remain editable, so you can prepare the configuration before SSO is in place. Confirm your configuration with your DataRobot representative before beginning.

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.

| スコープ | Who configures it | 環境 | 説明 |
| --- | --- | --- | --- |
| 全体 | System Administrator | Self-Managed, single-tenant SaaS | One configuration for the whole application. Works with the default organization or routes users to multiple organizations through organization mapping. |
| 組織 | System or Organization Administrator | managed AI Platform, single-tenant SaaS, Self-Managed | A separate configuration per organization. Configure multiple organizations independently, each with its own IdP and mapping. |

> [!NOTE] 備考
> The inbound OAuth configuration scope must match your single sign-on (SSO) scope: a global inbound OAuth configuration requires global SSO, and an organization configuration requires organization-level SSO.

## 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](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configuration-scope):

| スコープ | パス |
| --- | --- |
| 全体 | /admin/external-application-configuration |
| 組織 | /admin/org-external-application-configuration |

This table lists the settings found on the configuration page:

| ラベル | セクション | 説明 |
| --- | --- | --- |
| (1) | OAuth認証 | Enable or disable OAuth authentication for an external application. |
| (2) | OAuthの詳細 | Read-only, DataRobot-provided values your callers use: the token exchange endpoint, the token audience, and the DataRobot JWKS URI. |
| (3) | 外部IdPの設定 | The external issuer and JWKS URI DataRobot uses to validate incoming IdP tokens. |
| (4) | ユーザープロビジョニング | Enable automatic provisioning of new users. |
| (5) | マッピング | Map IdP token claims to DataRobot user attributes, groups, and scopes. Global configurations also have an Organizations tab. |
| (6) | 高度なオプション | Set how often DataRobot refreshes the IdP JWKS keys. |

### 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](https://docs.datarobot.com/ja/docs/api/dev-learning/inbound-oauth-tokens.html.md) for how each value is used.

| フィールド | 説明 |
| --- | --- |
| トークン交換のエンドポイント | The DataRobot endpoint a caller posts an IdP token to in exchange for a DataRobot access token. It includes the organization ID for an organization configuration. |
| オーディエンス | The audience (aud) value DataRobot requires in the exchanged token. |
| JWKS URI | The URI where DataRobot publishes the keys used to validate DataRobot-issued access tokens. |

### 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.

| フィールド | 必須 | 説明 |
| --- | --- | --- |
| 外部発行者 | はい | The issuer (iss) claim value to validate in incoming external JWT tokens. Tokens are accepted only if their issuer matches this value. |
| 外部JWKS URI | はい | The URI to fetch the JSON Web Key Set (JWKS) for validating incoming external JWT tokens. DataRobot caches these keys (see Advanced options). |

> [!NOTE] 備考
> The External JWKS URI is your IdP's key set, used to validate incoming tokens. It is different from the DataRobot JWKS URI shown in OAuth Details, which publishes DataRobot's own signing keys ( `/.well-known/jwks.json`) for validating DataRobot-issued 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.

**Okta:**
Create a custom authorization server. In the Okta Admin Console, go to
Security > API > Authorization Servers
and use or create a server dedicated to DataRobot.
The server's
Issuer URI
(for example,
https://YOUR_ORG.okta.com/oauth2/ausXXXXXXXX
) is the value you enter as
External issuer
.
Its JWKS URI is the issuer with
/v1/keys
appended; enter it as
External JWKS URI
.
Add the
dr.impersonation
scope. On the authorization server, go to
Scopes > Add Scope
and add a scope named
dr.impersonation
. DataRobot validates this scope on every token; without it, user access is denied.
Set the audience. Copy
External Application > OAuth Details > Audience
from DataRobot (it looks like
https://YOUR_DATAROBOT_HOST/ORGANIZATION_ID
) and set the authorization server's
Audience
to exactly that value. A mismatch fails the exchange with
invalid_target
. If the server must serve other audiences, create a dedicated server for DataRobot.
Add an access policy. On the authorization server, go to
Access Policies
and add a policy and rule that allow your app to request the
dr.impersonation
scope.
Create an app integration. Create an
OIDC app
that uses the
Authorization Code
flow (with PKCE), and assign the users who need API access. Your API clients use this app to sign users in and obtain tokens. Okta typically disables the Resource Owner Password grant, so use Authorization Code.
Confirm the claims. Make sure the access token carries the claims your
mapping
expects: username (Okta uses
sub
by default), scopes (Okta uses
scp
), and a
groups
claim if you use group mapping.

**Microsoft Entra ID:**
Register an app to represent DataRobot. In the Microsoft Entra admin center, go to
App registrations > New registration
. Open the new registration's
Expose an API
page and set the
Application ID URI
to the DataRobot audience from
External Application > OAuth Details > Audience
(for example,
https://YOUR_DATAROBOT_HOST/ORGANIZATION_ID
). This value becomes the token's
aud
. A custom identifier URI like this requires the
v2.0
access token format.
Expose the
dr.impersonation
scope. Still under
Expose an API
, select
Add a scope
and add a scope named
dr.impersonation
.
Set the issuer and JWKS URI. Open your tenant's OpenID configuration at
https://login.microsoftonline.com/TENANT_ID/v2.0/.well-known/openid-configuration
. Enter its
issuer
value as
External issuer
and its
jwks_uri
value as
External JWKS URI
. Match the token version your app issues (a v2.0 issuer looks like
https://login.microsoftonline.com/TENANT_ID/v2.0
).
Grant the client app access. In the client app registration your users sign in with, go to
API permissions
, add the
dr.impersonation
scope you exposed, and grant admin consent. Assign the users who need API access.
Confirm the claims. Entra access tokens carry scopes in
scp
and the username in
preferred_username
(or
upn
); map these in
mapping
. For group mapping, add the
groups
claim under the app's
Token configuration
.


### ユーザープロビジョニング

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

| フィールド | 説明 |
| --- | --- |
| ユーザーを自動生成 | If enabled, DataRobot provisions a new user account the first time a valid token arrives for a user who does not yet exist. The account is created from the token claims and added to the mapped organization. |

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 .

> [!NOTE] 備考
> If no non-builder seat is available, provisioning still succeeds; the user is created without a seat rather than blocked.

## 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.

| 方法 | エンドポイント | 説明 |
| --- | --- | --- |
| GET | /api/v2/externalApplicationConfigurations/ (global) or /api/v2/externalApplicationConfigurations/ORGANIZATION_ID/ (organization) | Retrieve a configuration. |
| POST | Same as GET | Create a configuration. |
| PATCH | Same as GET | Update a configuration. clientId and organizationId are immutable. |

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:

| オプション | 必須 | タイプ | デフォルト | 制限 | 説明 |
| --- | --- | --- | --- | --- | --- |
| organizationId |  | ObjectId | なし | 24 | ID of the target organization. Omit for a global configuration. Immutable. |
| isEnabled | はい | ブーリアン | false |  | Whether the configuration is active. |
| issuer | はい | 文字列 | "" | 256 | The issuer URL of the identity provider. |
| jwksUri | はい | 文字列 | "" | 256 | The JWKS URI of the identity provider. |
| autoGenerateUsers | はい | ブーリアン | false |  | If true, automatically provision users on first login via the IdP. |
| groupDelimiter |  | 文字列 | "" | 4 | Delimiter used to split group claims. |
| scopeDelimiter |  | 文字列 | "" | 4 | Delimiter used to split scope claims. |
| clientId |  | 文字列 | オート |  | Auto-generated unique client identifier. Immutable. |
| attributesMapping.username | はい | 文字列 | "" | 128 | Claim name for the username. |
| attributesMapping.displayName |  | 文字列 | "" | 128 | Claim name for the display name. |
| attributesMapping.firstName |  | 文字列 | "" | 128 | Claim name for the first name. |
| attributesMapping.lastName |  | 文字列 | "" | 128 | Claim name for the last name. |
| attributesMapping.email |  | 文字列 | "" | 128 | Claim name for the email. |
| attributesMapping.groups |  | 文字列 | "" | 128 | Claim name for the groups. |
| attributesMapping.scopes | はい | 文字列 | "" | 128 | Claim name for the scopes. The mapped claim must include the required dr.impersonation scope. |
| attributesMapping.organization |  | 文字列 | "" | 128 | Claim name for the organization. Organization scope only. |
| groupMapping |  | Dictionary | {} |  | Mapping of IdP group names to DataRobot group IDs. |
| organizationMapping |  | Dictionary | {} |  | Mapping of IdP organization names to DataRobot organization IDs. Global scope only. |
| groupMappingPerOrganization |  | Dictionary | {} |  | Group mapping per organization. Global scope only. |
| advancedConfiguration.jwksRefreshIntervalSeconds |  | 数字 | 3600 | 0–604800 | Interval, in seconds, for refreshing JWKS keys. |

## 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](https://docs.datarobot.com/ja/docs/platform/admin/sso-ref.html.md#mapping).

### 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.

| DataRobot attribute | Example claim | 必須 |
| --- | --- | --- |
| 表示名 | name |  |
| ユーザー名 | preferred_username | はい |
| 名 | given_name |  |
| 姓 | family_name |  |
| メールアドレス | email |  |

### 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](https://docs.datarobot.com/ja/docs/platform/admin/manage-entities/manage-groups.html.md). 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.

| フィールド | 説明 |
| --- | --- |
| グループ属性 | The claim that identifies group names in the token. |
| グループ区切り文字 | The delimiter between group names when the claim is a single delimited string. |
| DataRobotグループ | The existing DataRobot group to assign the user to. |
| IDプロバイダーグループ | The IdP group the user belongs to. |

### 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.

| フィールド | 必須 | 説明 |
| --- | --- | --- |
| スコープ属性 | はい | The claim that identifies scopes in the token (for example, scp or scope). |
| スコープ区切り文字 |  | The delimiter between scopes when the claim is a single delimited string. |

> [!NOTE] 重要
> Configure your IdP to include the `dr.impersonation` scope in the access tokens users present for exchange. Without it, DataRobot doesn't grant API access to the user. Share this requirement with your developers, who set it up in your IdP's authorization server or app registration.

### 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.

| フィールド | 説明 |
| --- | --- |
| 組織の属性 | The claim that identifies the organization in the token. |
| DataRobotの組織 | The existing DataRobot organization to assign the user to. |
| アイデンティティプロバイダーの組織 | The IdP organization the user belongs to. |

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

## 高度なオプション

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.

| 設定 | Set via | プラットフォーム | デフォルト | 説明 |
| --- | --- | --- | --- | --- |
| jwksRefreshIntervalSeconds | Admin UI or config API | SaaS, Self-Managed | 3600 | How often DataRobot refreshes cached JWKS keys, in seconds (0–604800). |
| DR_JWT_JWKS_URI_FRESHNESS | Cluster configuration | Self-Managed (DataRobot-managed on SaaS) | 600 | JWKS cache freshness, in seconds, for the application. |
| DR_JWT_LEEWAY | Cluster configuration | Self-Managed (DataRobot-managed on SaaS) | 0 | Seconds past a token's exp claim that a token is still accepted, to tolerate clock skew. |
| EXTERNAL_APPLICATION_AUTHENTICATION_JWKS_URI_PROXY | Cluster configuration | Self-Managed (DataRobot-managed on SaaS) | {} | Proxy for outbound JWKS requests, defined per protocol (http, https). |
| DR_JWT_AUDIENCE_OVERRIDE | Cluster configuration | Self-Managed (DataRobot-managed on SaaS) | "" | Overrides the base URL of the token audience for the whole application. |

## Audit logs

Inbound OAuth records the following events in the [User Activity Monitor](https://docs.datarobot.com/ja/docs/reference/misc-ref/uam-ref.html.md):

| イベント | 説明 |
| --- | --- |
| External token exchanged | An IdP token was exchanged for a DataRobot access token. |
| Inbound OAuth configuration created | An administrator created a configuration. |
| Inbound OAuth configuration updated | An administrator updated a configuration. |

## 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](https://docs.datarobot.com/ja/docs/platform/admin/inbound-oauth.html.md#configure-inbound-oauth) for the admin setup and [the developer workflow](https://docs.datarobot.com/ja/docs/api/dev-learning/inbound-oauth-tokens.html.md) for the token-exchange steps.

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

[SAML SSO](https://docs.datarobot.com/ja/docs/platform/admin/sso-ref.html.md) 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.

## 関連情報

- 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.