---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# OAuth Inbound

# OAuth Inbound {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Inbound

OAuth Inbound authentication in ServiceNow allows trusted external applications to securely access ServiceNow APIs.
This ensures controlled and authorized connections from third-party systems or other ServiceNow instances.
To configure or manage OAuth integrations, users must have theoauthadmin,miadmin, oradminrole.
Show full answer Show less  
Inbound OAuth authentication confirms that only trusted clients can access your ServiceNow environment in a secure manner.

## OAuth 2.0 Grant Types and Use Cases

ServiceNow supports multiple OAuth 2.0 grant types tailored for different integration scenarios. Selecting the right grant type depends on your specific use case:

* **Authorization Code Grant:** Best for applications accessing user data with user consent, such as web, mobile, or desktop apps. It involves user login and consent, exchange of an authorization code for an access token, and supports confidential clients and public clients with PKCE. This is the most secure and widely recommended flow for user-facing integrations.
* **Client Credentials Grant:** Suitable for backend services or automated integrations that access ServiceNow APIs without user involvement. The client authenticates using its own credentials (client ID and secret) to obtain an access token.
* **Third Party ID Token Flow:** Designed for federated authentication where ServiceNow trusts identity tokens from external identity providers like Azure AD or Okta. Enables seamless single sign-on and federated authentication by validating third-party tokens.
* **JWT Bearer Grant:** Used for secure access without user interaction or storing shared secrets. The client creates a signed JSON Web Token (JWT) asserting identity, which ServiceNow validates to issue an access token. It supports acting on behalf of a user or as the client application itself and offers a secure alternative to client credentials grant.
* **Resource Owner Password Credentials Grant:** Intended for highly trusted internal applications in controlled environments. The client collects user credentials directly to obtain an access token, bypassing redirection and consent screens. This flow is not recommended for general use due to security risks.
* **Implicit Grants:** Used by legacy single-page or browser-based applications that cannot securely store client secrets. The access token is returned directly in the URL after login, simplifying the flow but increasing token exposure risk. ServiceNow recommends using authorization code grant with PKCE for stronger security instead.

## OAuth Scopes

OAuth scopes in ServiceNow restrict OAuth authentication to specific REST APIs, providing granular control over API access. This helps enforce security by limiting OAuth tokens to only the APIs necessary for the integration.  
OAuth Inbound authentication allows trusted external applications to securely access ServiceNow APIs, ensuring controlled and authorized connections.  
You must have one of the following roles to configure or manage OAuth integrations in the system:

* <kbd class="ph userinput">oauth_admin</kbd>
* <kbd class="ph userinput">mi_admin</kbd>
* <kbd class="ph userinput">admin</kbd>
{#oauth-inbound__ul_egf_vyt_xfc}

Inbound authentication enables external applications such as third-party systems or other ServiceNow® instances to connect securely to ServiceNow APIs. Inbound authentication confirms that only trusted clients can access your ServiceNow instance in a controlled and secure manner. ServiceNow supports several OAuth 2.0 grant types, each designed for specific integration scenarios. Use the following information to choose the grant type that best fits your use case:

## Authorization Code Grant {#oauth-inbound__section_slq_plt_xfc}

{#oauth-inbound__table_bs4_2jj_wfc__entry__2}

| Ideal usage scenario | Functionality |
|-|-|
| Applications that must access user data on behalf of user with the user's consent. Example: Web, mobile, or desktop applications acting on behalf of a user. | The user initiates the login process from the client application, which redirects them to a ServiceNow login page. After the user logs in and grants consent, the client application receives an authorization code. The client application exchanges the authorization code with the ServiceNow instance for an access token. Authorization code grant is the most secure and widely used workflow for user-facing integrations. It supports both confidential clients (with a client secret) and public clients using Proof Key for Code Exchange (PKCE). |
[ ]

{#oauth-inbound__table_bs4_2jj_wfc}

For more information about Authorization code grant workflow and configuration, see

## Client Credentials Grant {#oauth-inbound__section_qc5_tlt_xfc}

{#oauth-inbound__table_ybk_5jj_wfc__entry__2}

| Ideal Usage Scenario | Functionality |
|-|-|
| Client applications such as back-end services or automated system integrations that must access ServiceNow APIs without user involvement. | The client application authenticates directly with the ServiceNow instance using its own credentials (client ID and secret). Once authenticated, the application receives an access token to access the ServiceNow APIs. |
[ ]

{#oauth-inbound__table_ybk_5jj_wfc}

For more information about Client credentials grant workflow and configuration, see .

## Third party ID Token Flow {#oauth-inbound__section_i1h_kwt_xfc}

{#oauth-inbound__table_dxy_mkj_wfc__entry__2}

| Ideal Usage Scenario | Functionality |
|-|-|
| Federated authentication scenarios where ServiceNow trusts identity tokens issued by external identity providers such as Azure AD or Okta. | The client application obtains an ID or access token from a trusted third-party identity provider, and includes it in the authorization header when making API requests to the ServiceNow instance. ServiceNow validates the token and, if trusted, grants access based on the identity it asserts. This enables seamless single sign-on (SSO) and federated authentication across systems. |
[ ]

{#oauth-inbound__table_dxy_mkj_wfc}

For more information about Third party token flow and configuration, see.

## JWT Bearer Grant {#oauth-inbound__section_wvj_wlt_xfc}

{#oauth-inbound__table_vn1_zjj_wfc__entry__2}

| Ideal Usage Scenario | Functionality |
|-|-|
| Client applications that need secure access to ServiceNow resources, either on behalf of a user or as themselves, without requiring user interaction or storing a shared secret. The client application creates a signed JSON Web Token (JWT) that includes identity-related claims, such as the user or system it represents. It then presents it to the ServiceNow instance to request for access token. | When acting on behalf of a user: :   The token represents a previously authenticated user. This enables secure, seamless access without prompting the user for credentials or consent again. The signed token asserts the user's identity, enabling ServiceNow to trust the request without requiring real-time user interaction. When acting as itself: :   The token identifies and authenticates the client application directly. Instead of using a shared secret, the client signs the token with a private key, making it a more secure alternative to the client credentials grant. |
[ ]

{#oauth-inbound__table_vn1_zjj_wfc}

For more information about JWT bearer grant workflow and configuration, see .

## Resource Owner Password Credentials Grant {#oauth-inbound__section_m45_3wt_xfc}

{#oauth-inbound__table_mkv_jkj_wfc__entry__2}

| Ideal Usage Scenario | Functionality |
|-|-|
| Highly trusted internal client applications in controlled environments where the app collects the user's credentials directly. | The client application collects the user's user name and password, and redirects them to the ServiceNow instance to obtain an access token. The workflow bypasses redirection and consent screens, but exposes user credentials to the client application. ServiceNow recommends that you implement the Resource owner password credentials grant only in legacy or controlled environments. |
[ ]

{#oauth-inbound__table_mkv_jkj_wfc}

For more information about Resource owner password credentials grant workflow and configuration, see [Resource owner password credential grant](https://www.servicenow.com/docs/zv_Zk22KocGiXX_N4iSKEw "Configuring an OAuth Resource Owner Password Credential (ROPC) grant enables applications to authenticate users by directly using their credentials to obtain an access token.").

## Implicit Grants {#oauth-inbound__section_k23_fwt_xfc}

{#oauth-inbound__table_wmj_2lt_xfc__entry__2}

| Ideal Usage Scenario | Functionality |
|-|-|
| Legacy Single-page applications (SPAs) or browser-based apps that can't securely store a client secret, and require a lightweight, client-side authentication flow. | The user logs in through a browser. The client application receives the access token directly in the URL after login, bypassing the intermediate authorization code step. This flow was originally designed for public clients that run entirely in the browser, where securely storing secrets isn't possible. While it simplifies implementation, it exposes tokens in the browser, increasing the risk of interception. For stronger security, ServiceNow recommends implementing an authorization code grant with PKCE. |
[ ]

{#oauth-inbound__table_wmj_2lt_xfc}

For more information about Implicit grant workflow and configuration, see [OAuth implicit grants](https://www.servicenow.com/docs/BVrZO28a9O4NEhl6J5oFxA "ServiceNow instances support the implicit grant of an access token.").

## OAuth Scopes {#oauth-inbound__section_cy4_xyq_cxb}

You can scope the OAuth authentication scope support for REST API. OAuth Scope provides access to only the particular REST APIs. For more information, see [REST API Auth Scope](https://www.servicenow.com/docs/QL3mKi5Tqy6G5rFYcRplVA "Use the REST API Auth Scope to provide access to a specific REST API").