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.
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.disabledis 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.