OAuth Grant Types in ServiceNow — A Practical Guide for External Integrations

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 four main OAuth grant types in ServiceNow, 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

• 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

• 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 Four Main OAuth Grant Types in ServiceNow

1. Client Credentials (Most Common for Integrations)

Best for:

• Server-to-server integrations

• Tools that authenticate using only client ID + secret

• Automated systems with no user interaction

Examples:
AWS Glue, MuleSoft, Boomi, custom API clients, backend services.

How it works:
The integration uses:

• Client ID

• Client Secret

No user login, no redirect, no password.

Why it’s recommended:

• Simple

• Secure

• Stable

• No user dependency

• No browser interaction

• Works consistently across environments

Common error when not used:
Tools expecting this flow may receive “session expired” or CSRF errors when configured incorrectly as a different grant type.

---

2. Resource Owner Password Credentials (ROPC)

Best for:
Legacy applications that authenticate using a specific user’s username and password.

Why it’s risky:

• Requires storing a user’s password in an external system

• Breaks if password expires or the user is locked

• Not allowed in many organizations due to security policies

Why integrations fail with ROPC:
If the integration expects to authenticate using just client ID + secret (like Glue), but the OAuth registry uses ROPC:

• ServiceNow rejects the request

• Redirects to the login page

• The external system receives HTML instead of a token

• This triggers a misleading CSRF/session-expired error

Use only if:
You absolutely must impersonate a user and have no modern integration path.

---

3. Authorization Code Grant (with Redirect)

Best for:

• Web apps where a human signs in

• Browser-driven flows

• 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

• Longer setup

• Not suitable for automated systems

Why integrations fail with this:
If an automated tool uses this grant type, ServiceNow tries to redirect it to a login page → causing “session expired.”

---

4. Refresh Token Grant

Best for:
Extending an existing session without re-authenticating.

Works only after:
The Authorization Code or Resource Owner flow has already created a token.

Not used alone — it's always a secondary mechanism.

---

Grant Type Comparison Table

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
Authorization Code	Browser/web login	Yes	No	❌ No
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]

Look for the field:
Grant type

Allowed values will show one or more of:

• Client Credentials

• Resource Owner Password Credentials

• Authorization Code

• Refresh Token

If the wrong type is selected, update it and re-test.

---

Why Grant Type Issues Only Affect One Instance

A common scenario:

• Integration works in DEV

• Works in PROD

• ❌ Fails in TEST

This occurs because:

• Client ID is different

• Grant type is different

• Scopes differ

• Redirect URL differs

• The integration user is locked only in one instance

Even one field mismatch causes OAuth to break.

---

Best Practices for Reliable Integrations

✔ Always use Client Credentials for non-user-driven systems

Simple, predictable, secure.

✔ Avoid Resource Owner Password

Too risky and breaks easily.

✔ Disable unused grant types

Reduces confusion and improves security.

✔ Standardize OAuth registry across all instances

Use a controlled update set or automation job.

✔ Clearly document client ID + secret per environment

Prevents accidental cross-environment use.

---

Final Thoughts

Most integration failures in ServiceNow involving OAuth come down to one root cause: incorrect grant type selection. By understanding how each grant type works and matching it to the correct use case, teams can avoid authentication errors, remove support overhead, and ensure stable integrations across all environments.