Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

PrabhuShan
ServiceNow Employee
ServiceNow Employee

In today’s fast-paced digital landscape, secure and seamless integration between platforms is essential. With the latest release, we’re excited to introduce the new Inbound Integration experience within our Machine Identity Console. This enhancement simplifies OAuth client creation and delivers a significantly improved user experience for configuring inbound integrations in ServiceNow. Whether you’re building integrations for third-party apps, automating backend processes, or enabling federated authentication, choosing the right OAuth grant type is crucial for both security and usability. 

Inbound authentication allows external applications—such as third-party systems or other ServiceNow instances—to securely connect to ServiceNow APIs. This ensures that only trusted clients can access your ServiceNow instance in a controlled and secure way.  In this blog, let’s explore the different OAuth grant types supported by ServiceNow for Inbound API Authentication and learn how to choose the one that best fits your integration needs. 

PrabhuShan_1-1758250397010.png

 

Choose the Right Grant Type for Your Needs

Authorization Code Grant 

This grant type is especially useful if your client application is acting on behalf of a user and requires the user’s consent to act on their behalf. It is well-suited for web, mobile, or desktop applications that need to perform actions as the user. 

PrabhuShan_0-1758256617220.png

 

 

How it works: 

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, which it exchanges with the ServiceNow instance for an access token. This is the most secure and widely used flow for user-facing integrations. It supports both confidential clients (with a client secret) and public clients (using PKCE). 

In the Authorization Code Grant flow, ServiceNow functions as both the authorization server (handling user authentication and token issuance) and the resource server (hosting the APIs). If SSO is enabled, ServiceNow redirects the user to the configured Identity Provider (IdP) for authentication. After the IdP successfully authenticates the user, control returns to ServiceNow, which then issues the authorization code. This process ensures that even with external authentication, ServiceNow remains the authority for issuing tokens and managing API access.

Note: If you want to use your
own identity provider (such as Azure AD or Okta) as the authorization server, consider using the Third Party ID Token Grant flow.

Client Credentials Grant 

This grant type is best suited for scenarios where your client application needs to access ServiceNow APIs without any user involvement. It is commonly used by backend services, automated jobs, or system integrations that operate independently of a user’s identity. Since there is no user context, the actions performed using this grant type are attributed to the application itself. 

 

PrabhuShan_1-1758256697445.png



How it works: 

The client application authenticates directly with the ServiceNow instance using its own credentials (client ID and secret). Once authenticated, it receives an access token to access ServiceNow APIs. Because no user is involved, the access token represents the client application itself, not a user's identity. 


Third-Party ID Token Flow 

This grant type is ideal for federated authentication scenarios where ServiceNow needs to trust identity tokens issued by external identity providers, such as Azure AD or Okta. It is particularly useful when you want to allow users or services to authenticate using their organization’s existing credentials, enabling cross-platform trust and centralized identity management. 

PrabhuShan_3-1758257018257.png

 

How it works: 

The client application obtains JWT 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 using the public keys of the identity provider, and if trusted, grants access based on the identity it asserts—enabling federated authentication across systems. 

Note: This grant name is ServiceNow specific and is not part of the standard OAuth 2.0 specification. 

 

JWT Bearer Grant 

This grant type is well-suited for client applications that require secure access to ServiceNow resources, whether acting on behalf of a user or as themselves. It is particularly valuable when you want to avoid requiring user consent while acting on behalf of a user and eliminate the risk of a shared secret when acting as itself.

 

PrabhuShan_4-1758257099471.png

 

 

How it works: 

The client application creates a signed JWT (JSON Web Token) that includes identity-related claims—such as the user or system it represents—and presents it to the ServiceNow instance to request an access token. 

When acting on behalf of a user: 

The token represents a previously authenticated user, enabling secure, seamless access without prompting the user for credentials or consent again. This works by asserting the user’s identity through the signed token, allowing 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 just relying on a shared secret, the client signs the token with a private key, making it a more secure alternative to the Client Credentials Grant.

 

Resource Owner Password Credentials Grant 

This grant type is intended for highly trusted internal client applications operating in controlled environments where the application collects the user’s credentials directly. It is suited for legacy systems or scenarios where more secure alternatives are not feasible, and where both the client and environment can be fully trusted to handle sensitive user information. 

PrabhuShan_5-1758257184179.png

 

How it works: 

The client application collects the user’s username and password and sends them directly to the ServiceNow instance to obtain an access token. This flow bypasses redirection and consent screens but exposes user credentials to the client application, so it should only be used in legacy or tightly controlled environments where more secure alternatives are not feasible.

 


No matter your integration scenario—whether it’s user-driven, machine-to-machine, federated, or legacy—ServiceNow offers a grant type that fits your needs. Take advantage of the new Inbound Integration experience to streamline your OAuth client setup and confidently secure your API connections. The right choice today sets the stage for seamless, secure integrations tomorrow.