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.
