OAuth Grant Types in ServiceNow: A Practical Guide for External Integrations (Updated)

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.

A note on ROPC's status: ROPC is deprecated under the OAuth 2.1 specification, and ServiceNow provides a system property, 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.disabled to true once 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.

ServiceNow CSRF Token Errors in Integrations: Root Causes and Fixes (Updated)

CSRF protection in ServiceNow is designed to guard browser-based UI sessions, not machine-to-machine API traffic. So when an external tool such as AWS Glue receives "Invalid CSRF token" or "Your session has expired", the message is misleading. It almost never means CSRF protection is genuinely blocking the call — it usually means the authentication flow itself failed and ServiceNow silently redirected the request to a login page.

What makes this confusing is that the same integration often works fine against one instance and fails in another, which sends both teams chasing the wrong root cause.

This article explains why that happens and how to diagnose and fix it on current ServiceNow releases.

What actually causes "CSRF" errors in integrations

A ServiceNow CSRF-style error on an integration call almost always comes down to one of two things.

1. ServiceNow treats the request as a browser session instead of an API call. If the request hits a UI-oriented endpoint, or is missing headers that mark it as API traffic, ServiceNow applies session/CSRF validation rules meant for the browser.

2. The authentication flow fails and redirects. When OAuth token exchange fails, ServiceNow can redirect to a login page instead of returning a JSON error. The external system receives an HTML login page where it expected a token or API response, and that gets surfaced upstream as a session/CSRF error.

A properly authenticated, correctly scoped API call should never trigger a CSRF error. If you're seeing one, treat it as a symptom of an authentication or routing problem, not an actual CSRF violation.

Why AWS Glue (or similar tools) might trigger this

AWS Glue integrates with ServiceNow by performing OAuth authentication, then REST API reads/writes against /api/now/table/ endpoints. When that sequence breaks down, Glue typically surfaces one of the two messages above. Either one means ServiceNow did not accept the incoming credentials as valid API traffic and fell back to browser-session handling. The real causes are almost always one of the following.

1. Wrong or deprecated OAuth grant type

This is the most common root cause, and it has shifted in the last couple of release cycles. The current recommendation is to use the Client Credentials grant (client ID + client secret only, no end-user credentials) for machine-to-machine integrations like Glue. This is what ServiceNow documents as the correct pattern for service-to-service API access.

A note on ROPC: Resource Owner Password Credentials — the grant type that also requires a username and password — still exists on the platform, but it's now explicitly discouraged. It's deprecated under the OAuth 2.1 specification, and ServiceNow added a system property, glide.oauth.inbound.ropc.grant_type.disabled, that instance admins can (and increasingly do) set to true to block it outright.

If your instance has that property enabled and Glue (or its OAuth app registration) is still configured for ROPC, every token request will fail, ServiceNow will redirect toward a login page, and Glue will report it as a CSRF/session error — even though the actual cause is a disabled grant type. Check the OAuth Transaction Log for a disabled_grant_type error specifically; it's a fast way to confirm this cause.

2. OAuth client ID mismatch across environments

Each ServiceNow instance (dev, test, prod) has its own OAuth Application Registry entry and therefore its own client ID and secret, even for "the same" integration. A common failure pattern:

• Correct client ID configured for DEV
• Correct client ID configured for PROD
• Stale or incorrect client ID left over in TEST

Authentication fails silently against the mismatched environment, ServiceNow falls back to the login URL, and the resulting error looks like a CSRF failure rather than what it is — a credentials mismatch.

3. Identity provider "External Logout Redirect" misconfiguration

If your instance uses an external identity provider, check the External Logout Redirect setting. When OAuth authentication fails, some configurations redirect to this URL instead of returning a proper error response. Glue then receives an HTML "session expired" page instead of JSON, and that gets interpreted downstream as a CSRF failure. The fix is usually to correct the redirect target, not to touch CSRF settings at all.

4. The integration user account is locked, inactive, or has an expired password

If the integration relies on a specific ServiceNow user account (common with ROPC, but also relevant if a service account is tied to token issuance), that account has to be active, unlocked, and — if ROPC is somehow still in play — have a valid, non-expired password. If the account is locked in one environment but not another, you'll see the integration work everywhere except that one instance, which is exactly the confusing pattern this article opened with.

5. Instance-specific redirect or SSO policy differences

One instance may simply have stricter security posture than another — a tighter SSO policy, more restrictive login rules, or IP allowlisting that the integration's egress IPs don't match. Any of these can cause OAuth to fail in one environment while working fine in another with an otherwise identical configuration.

6. The API endpoint is being treated as a UI page

If the integration is pointed at a UI-facing URL instead of a proper REST endpoint under /api/now/ — even something as small as a missing /now segment — ServiceNow applies browser session rules and enforces CSRF validation. Double-check the full endpoint path, not just the base instance URL.

7. OAuth scope mismatch

If the OAuth Application Registry on the target instance defines a specific set of scopes and Glue's OAuth client is configured to request a scope that isn't registered there, the token request is rejected and ServiceNow redirects to login — again surfacing as "session expired." This is worth checking specifically when an integration works in one instance and not another with a similarly named but differently scoped OAuth registration.

How to diagnose this systematically

Step 1 — Check the OAuth Transaction Logs. Navigate to System OAuth > Application Registry, open the relevant entry, and review its OAuth Transaction Logs. Failed transactions will show the actual cause directly: wrong or disabled grant type, invalid client ID, unexpected redirect, or a specific authentication error code.

Step 2 — Verify the integration user, if a user-based flow is involved. Check that the account is active, not locked, and — if a password-based flow is somehow still configured — that the password hasn't expired.

Step 3 — Compare the OAuth Application Registry across instances. Check these fields side by side between the working and failing instance:

• OAuth application name
• Client ID
• Client Secret
• Token URL
• Redirect URL
• Grant type(s) enabled
• Scopes
• Whether glide.oauth.inbound.ropc.grant_type.disabled is set differently between instances

When an integration works in one instance and fails in another, at least one of these fields is the difference.

Step 4 — Get logs from the external tool. Ask the Glue (or equivalent) team for their request/response logs. You're looking for whether the token endpoint returned JSON or an HTML login page, what the actual redirect URL was, and the raw HTTP status code. If they got a login page instead of a token or API response, the OAuth flow — not CSRF — is the problem.

Step 5 — Confirm the correct endpoints are being called. The token request should go to:

https://<instance>.service-now.com/oauth_token.do

and API calls should be scoped under:

/api/now/table/

Anything else gets treated under browser/UI rules, which is where CSRF enforcement kicks in.

Final thoughts

CSRF-labeled errors in ServiceNow integrations are almost always a downstream symptom of an OAuth authentication or configuration issue — not an actual CSRF violation. On current releases, that most often traces back to a deprecated or disabled ROPC grant type, since ServiceNow has been actively pushing instances toward Client Credentials for machine-to-machine integrations.

Work through grant type, client ID/secret accuracy, scopes, redirect configuration, integration user status, and endpoint URLs in that order, and you'll typically isolate the real cause — and get the integration back online — within minutes rather than hours.

---

This article reflects current ServiceNow guidance on OAuth 2.0 authentication for inbound integrations, including the ongoing deprecation of the Resource Owner Password Credentials grant type. Exact system property names and default behavior can vary by release family — verify against your instance's OAuth Transaction Logs and System Properties before making changes.