OAuth 2.0 credentials

  • Release version: Zurich
  • Updated July 20, 2026
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of OAuth 2.0 credentials

    OAuth 2.0 credentials in ServiceNow enable secure access to user accounts on HTTP services by facilitating OAuth token requests. These credentials are configured in the Credentials form and are essential for integrating ServiceNow with third-party OAuth providers or on-premise/cloud OAuth servers, especially when using MID Servers for secure connectivity.

    Show full answer Show less

    Key Features

    • Name: Assign a unique, descriptive name to identify the credential clearly.
    • Active: Toggle to specify whether the credential is currently active.
    • OAuth Entity Profile: Defines the grant type and scopes used for authorization, linking the credential to OAuth configurations.
    • Connect to Auth Server via MID Server: Enables routing OAuth token requests through a MID Server, allowing secure communication with OAuth servers behind firewalls or in the cloud.
    • Applies to: Determines which MID Servers (all or specific ones) the credential applies to, requiring proper communication and configuration for token requests.
    • Order: Sets priority for credential use during device login attempts, important for managing multiple credentials and avoiding lockouts.
    • Credential Alias: Allows linking the OAuth 2.0 credential to an alias for easier identification and management.
    • Integration Type: Specifies whether the OAuth token is system-wide or user-specific:
      • System: Retrieves tokens based on the requester profile using mechanisms like SAML or JWT.
      • Personal: Retrieves user-specific tokens; requires the MID Server user to have the oauthadmin role and supports user-related OAuth tokens.

    Important Considerations for MID Server Use

    • Ensure MID Servers specified in Applies to can communicate with the OAuth Auth server.
    • At least one MID Server must have Status as Up, Validated as Yes, and capability set to REST or ALL.
    • MID Server users managing OAuth integrations must have the oauthadmin role.

    Practical Application

    ServiceNow customers can use OAuth 2.0 credentials to securely authenticate and authorize API calls to third-party services, leveraging either system-wide or user-specific tokens. When integrating with internal or cloud OAuth servers behind firewalls, routing token requests through MID Servers ensures secure, manageable connectivity. Proper configuration of credential order and MID Server applicability helps streamline authentication workflows and prevents access issues.

    OAuth 2.0 credentials enable ServiceNow to obtain access to user accounts on an HTTP service.

    These fields are available in the Credentials form for OAuth 2.0.
    Table 1. OAuth 2.0 credentials form
    Field Input value
    Name Enter a unique and descriptive name for this credential. For example, you might call it OAuth2 credential.
    Active Specify whether this credential is active.
    OAuth Entity Profile An OAuth profile is a combination of a grant type and at least one scope.
    Connect to Auth Server via MID Server Connects your ServiceNow instance to an on-premise OAuth server that resides behind a firewall through a MID Server. It can also connect your ServiceNow instance to a cloud-based OAuth server through a MID server. When this option is enabled, the request for an OAuth token is sent through the MID Server.
    Important:
    • The option appears when the value in the Grant type field in the OAuth Entity Profile is set to eitherClient Credentials, Authorization Code, or Resource Owner Password Credentials. To learn how to set an OAuth entity profile for a third-party OAuth provider, see Connect to a third-party OAuth provider.
    • If you select the Connect to Auth Server via MID Server checkbox, you must identify the required MID Server or MID Servers from the Applies to list.
    • MID Server user needs the oauth_admin role to Set up OAuth integration via MID Server.
    Applies to

    Specify if the credential record is applicable for all MID Servers, or a specific MID Server. If specific, add the MID servers as necessary.

    Important:

    Ensure that you are aware of these considerations if you have selected the Connect to Auth Server via MID Server check box.
    Order

    Order (sequence) in which Discovery tries this credential as it attempts to log on to devices. The smaller the number, the higher in the list this credential appears. Establish credential order when using large numbers of credentials or when security locks out users after three failed login attempts. If all the credentials have the same order number (or none), the instance tries the credentials in a random order.
    Credential alias Specify the credential alias that you want to tie to the OAuth 2.0 credential.
    Integration Type Indicates the integration type for the credential. Invoke an API of a third-party with an OAuth request that generates an OAuth token that is system or user specific. Following are the integration types:
    • System: Pull the token information based on the requester profile. The System integration type supports the following authentication mechanisms:
      1. Security Assertion Markup Language (SAML)
      2. JSON Web Token (JWT)
    • Personal: Pull the token information that is user-specific. The MID Server user must have the oauth_admin role. The Personal and System integration types support the following grant types:
      1. Authorization Code
      2. Resource Owner Password Credentials

    If this Personal is selected on the OAuth Requestor Profile page, an additional flag called as Personal is displayed.

    Note:
    • Any information that is related to a user can only be accessed with user-specific OAuth tokens with the Integration Type as Personal.
    • To use the session user-related token, you have to select the Run As filed in the Flow properties as User who initiates session.