--- title: Configure a third party ID token description: Configure a third-party ID token to enable secure authentication by verifying user identities through an external IdP. The third-party ID token improves security by reducing stored credentials, confirms seamless authentication, and supports interoperability with industry standards like OpenID Connect \(OIDC\). locale: en-US canonical_url: https://www.servicenow.com/docs/r/australia/platform-security/authentication/configure-a-third-party-id-token.html release: australia product: Authentication classification: authentication topic_type: task last_updated: "2026-03-12" reading_time_minutes: 3 breadcrumb: [Third Party Token Grant, Inbound Integrations, OAuth Inbound, OAuth authentication, Authentication, Access Management] --- # Configure a third party ID token Configure a third-party ID token to enable secure authentication by verifying user identities through an external IdP. The third-party ID token improves security by reducing stored credentials, confirms seamless authentication, and supports interoperability with industry standards like OpenID Connect \(OIDC\). ## Before you begin Role required: `oauth_admin, mi_admin, admin` ## Procedure 1. Navigate to **Machine Identity Console** > **Inbound integrations** > **New integration** > **Third party ID token issued by OIDC supporting identity provider**. 2. Update the text fields in the **Details** form with the appropriate information.
Field Description
**Name** The name provided by the resource owner \(user\) during authentication.
**Provider name** Enter the name of the service provider you want to integrate with. Example: Microsoft, Google, Zoom, SAP, etc.**Note:** Provider name is a mandatory field.
**Client ID** The unique ID assigned to identify the application. Unique ID is the Audience value.
**Comments** Add any notes about this configuration.
**Active** Select to use for authentication and authorization requests; when unselected, the record is saved but remains inactive and will not process any requests.
3. Choose one of the two options from the OAuth OIDC provider configuration: 1. Use **Select an existing configuration** when an OIDC provider configuration already exists and provide the following details: |Field|Description| |-----|-----------| |**OIDC provider** \(required\)|Use the drop-down list to select the saved OIDC provider configuration.| |**OIDC provider name** \(auto-filled, read-only\)|Displays the name of the configuration selected in the drop-down.| |**OIDC metadata URL** \(auto-filled, read-only\)|The provider's well-known discovery endpoint, which exposes the signing keys and endpoints used to validate tokens. Example: `https://login.microsoftonline.com/common/.wellknown/openid-configuration`| |**OIDC configuration cache lifespan \(hours\)** \(auto-filled, read-only\)|How long, in hours, the system caches the provider's metadata before refetching it.| |**User claim** \(read-only\)|The token claim used to identify the user. Example: The claim whose value maps to a user record.| |**User field** \(read-only\)|The local user-record field that the user claim is matched against. Determines how an incoming token is mapped to an existing user. Example: `Email`.| |**Enable JTI verification**|When enabled, the system checks the token's JTI \(JWT unique ID\) to prevent token replay.| **Note:** Because these values are inherited, the metadata URL, cache lifespan, user claim/field, and JTI settings can't be edited directly here. Use the pencil icon option to modify the source configuration. 2. Use **Create a new configuration** when you want to define a new OIDC provider configuration and provide the following details:
Field Description
**New OAuth OIDC provider Configuration Name** \(required\) A unique name for the configuration you're creating.
**OIDC metadata UR**L \(required\) The provider's well-known discovery endpoint, which exposes the signing keys and endpoints used to validate tokens. Example: `https://login.microsoftonline.com/common/.wellknown/openid-configuration`
**OIDC configuration cache lifespan \(hours\)** \(required\) How long, in hours, the system caches the provider's metadata before refetching it.
**User claim** \(optional\) The token claim used to identify the user. Example: The claim whose value maps to a user record. `User claim` default is `sub`
**User field** \(optional\) The local user-record field that the user claim is matched against. Determines how an incoming token is mapped to an existing user. Example: `Email`.
**Enable JTI verification** When enabled, the system checks the token's JTI \(JWT unique ID\) to prevent token replay.
**JTI claim** The name of the token claim that carries the JTI value the system should validate. Defaults to the standard `jti` claim. Example: `jti`**Note:** Appears when JTI verification is enabled.
4. Perform the following steps to add auth scope to the configuration: 1. Select **Create auth scope** if you want to define a new scope. 2. Select a scope from the **Auth scope** drop-down. 3. Enter API names in **Limit authorization to the following APIs** to narrow access. 4. Use **+ Add another row** to assign additional scopes to your configuration. 5. Select **Allow access only to APIs in selected scope** in the Scope validation settings to restricts access to listed scopes only. **Note:** You can choose not to select **Set Allow access only to APIs in selected scope** for broader access permitted by user controls and API policies. 6. Select **Save** to create the configuration.