Choosing the wrong OAuth grant type is one of the most common causes of failed integrations in ServiceNow. Symptoms include:
- Session expired messages
- Invalid CSRF token errors
- Unexpected redirects to login pages
- Token endpoint failures
- API calls succeeding in one instance but failing in another
This article explains the five OAuth grant types ServiceNow supports for inbound integrations, what each one is designed for, and which external tools should use which flow.
Why grant type matters
When an external tool requests an access token, ServiceNow evaluates how the client identifies itself, whether a user's credentials are required, whether a redirect URL is needed, and whether the request is browser-based or server-to-server.
If the wrong grant type is used, ServiceNow may reject the request, redirect to a login page, return HTML instead of JSON, or treat the call as UI traffic and enforce CSRF protection. This is why integrations like AWS Glue, which expect simple JSON token responses, fail when the grant type is incorrect.
The OAuth grant types available in ServiceNow
1. Client Credentials (most common for integrations)
Best for: server-to-server integrations, tools that authenticate using only a client ID and secret, and automated systems with no user interaction.
Examples: AWS Glue, MuleSoft, Boomi, custom API clients, backend services.
How it works: the integration authenticates with a client ID and client secret only. No user login, no redirect, no password.
Why it's recommended: it's simple, secure, stable, has no user dependency or browser interaction, and behaves consistently across environments — which is exactly why ServiceNow documents it as the standard for machine-to-machine access.
Common error when not used: tools expecting this flow may receive "session expired" or CSRF errors when the OAuth registry is configured with a different grant type instead.
2. Resource Owner Password Credentials (ROPC)
Best for: legacy applications that authenticate using a specific user's username and password.
Why it's risky: it requires storing a user's password in an external system, breaks if that password expires or the user is locked, and is disallowed under many organizations' security policies.
glide.oauth.inbound.ropc.grant_type.disabled, that admins can set to true to block it instance-wide. If that property is enabled and an OAuth app registry is still set to ROPC, every token request against it will fail outright.
Why integrations fail with ROPC: if the integration expects to authenticate using just a client ID and secret (like Glue), but the OAuth registry is set to ROPC, ServiceNow rejects the request and redirects to the login page. The external system receives HTML instead of a token, which surfaces as a misleading CSRF or session-expired error.
Use only if: you absolutely must impersonate a specific user and have no modern integration path — and even then, treat it as a temporary measure rather than a long-term design choice.
3. Authorization Code Grant (with redirect)
Best for: web apps where a human signs in, browser-driven flows, and portals that require explicit user consent.
Examples: custom web apps, portals, internal tools with UI login pages.
Characteristics: requires a redirect URL, requires a human user, has a longer setup, and is not suitable for automated systems. Confidential clients use a client secret; public clients (mobile apps, SPAs) can use PKCE (Proof Key for Code Exchange) instead, which avoids storing a secret on a client that can't keep one safe.
Why integrations fail with this: if an automated tool uses this grant type, ServiceNow tries to redirect it to a login page, which causes "session expired."
4. JWT Bearer Grant
Best for: secure server-to-server access, either on behalf of a user or as the client application itself, without requiring real-time user interaction or a stored shared secret.
How it works: the client creates a signed JSON Web Token containing identity claims and presents it to ServiceNow's token endpoint. ServiceNow validates the signature and claims before issuing an access token — no password or interactive login involved.
When to use it over Client Credentials: when you need the extra assurance of a cryptographically signed request, or need to assert a specific identity (user or system) without exchanging a long-lived shared secret. For most simple system-to-system scenarios, Client Credentials remains simpler to set up and is the more common default.
5. Refresh Token Grant
Best for: extending an existing session without re-authenticating.
Works only after: the Authorization Code or JWT Bearer flow has already created a token. Not used alone — it's always a secondary mechanism layered onto another grant type.
Grant type comparison
| Grant Type | Use Case | Requires User Login | Works for Automation | Recommended for APIs |
|---|---|---|---|---|
| Client Credentials | Server-to-server | No | Yes | Yes |
| Resource Owner Password | Legacy user-based auth | Yes | No | No (deprecated) |
| Authorization Code (+ PKCE) | Browser/web login | Yes | No | Not for automation |
| JWT Bearer | Signed, secretless server-to-server | No | Yes | Yes (advanced) |
| Refresh Token | Extend existing token | Sometimes | Yes | Conditional |
How to check the grant type in ServiceNow
Go to System OAuth > Application Registry > [Your OAuth App] and look for the Grant type field. Allowed values will show one or more of: Client Credentials, Resource Owner Password Credentials, Authorization Code, JWT Bearer, and Refresh Token. If the wrong type is selected, update it and re-test.
Why grant type issues only affect one instance
A common scenario: the integration works in DEV, works in PROD, but fails in TEST. This happens because the client ID is different, the grant type is different, scopes differ, the redirect URL differs, or the integration user is locked only in that one instance. Even a single field mismatch is enough to break OAuth.
Best practices for reliable integrations
- Use Client Credentials (or JWT Bearer) for non-user-driven systems. Simple, predictable, secure.
- Avoid Resource Owner Password Credentials — it's deprecated, risky, and breaks easily. Consider setting
glide.oauth.inbound.ropc.grant_type.disabledtotrueonce you've confirmed nothing still depends on it. - Disable unused grant types on each OAuth application registry to reduce confusion and shrink the attack surface.
- Standardize OAuth registry configuration across all instances using a controlled update set or automation job, rather than manual per-instance setup.
- Clearly document client ID and secret per environment to prevent accidental cross-environment use.
Final thoughts
Most OAuth-related integration failures in ServiceNow come down to one root cause: incorrect grant type selection. By understanding how each of the five grant types works and matching it to the correct use case, teams can avoid authentication errors, reduce support overhead, and keep integrations stable across every environment.
This article reflects ServiceNow's current OAuth Inbound documentation, including JWT Bearer and PKCE support for Authorization Code. Available grant types and default behavior can vary by release family and active plugins — verify against your own instance's Application Registry before making changes.