Outbound Web Services — Authentication & Authorization Failures - Support and Troubleshooting

Outbound Web Services — Authentication & Authorization Failures .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Contents

1. Issue 2. Auth Types and How ServiceNow Sends Credentials 3. Root Causes 3.1 Authorization header absent — auth profile not attached or credentials blank 3.2 OAuth token expired or not refreshing 3.3 Intermittent 401 — node-specific token cache 3.4 403 Forbidden — credentials valid but insufficient permissions 3.5 403 Forbidden — works in Postman, fails in ServiceNow 3.6 MID Server — Unable to encrypt token 3.7 Basic Auth — invalid username/password 3.8 Flow Designer REST Action not sending credentials 4. MID Server — Additional Diagnostics 5. Diagnostic Steps 6. Resolution Summary 7. Related Articles

1. Issue Outbound REST or SOAP calls from ServiceNow reach the endpoint successfully but are rejected at the authentication or authorization layer. The connection and TLS handshake completed — the failure is in the credentials or permissions, not the network.

Symptoms this article covers:

Endpoint returns HTTP 401 Unauthorized. Endpoint returns HTTP 403 Forbidden. The same call works in Postman with the same credentials but fails from ServiceNow. The call works intermittently — succeeds on some requests, fails on others from the same instance. Error message contains: User is not authenticated , OAuth token has expired or has not been retrieved , Unable to encrypt token , Invalid username/password combo , Insufficient Permissions . The Authorization header is absent from the Request tab in sys_outbound_http_log . Outbound REST Action in Flow Designer intermittently stops sending credentials. Connection vs. auth failure — quick check

If the response status in sys_outbound_http_log is HTTP 0 or -1 (no status code at all), the failure is a connection or TLS issue, not an auth issue. See KB3067060 — Outbound Web Services — Connection Failures & TLS Errors . This article applies only when a real HTTP status code (401 or 403) is returned.

2. Auth Types and How ServiceNow Sends Credentials ServiceNow supports four outbound authentication types. Each has its own configuration path and its own failure signature. Identifying which type your integration uses is the first step in any auth failure investigation.

For OAuth 2.0 specifically, understanding the token acquisition flow is critical because failures can occur at multiple points in the sequence — not just at the API call itself.

3. Root Causes 3.1 Authorization header absent — auth profile not attached or credentials blank The most immediately diagnosable pattern. Open the Outbound HTTP log record, go to the Request tab , and look for the Authorization header. If it is absent or empty, ServiceNow never sent credentials at all.

Common causes:

The auth profile record exists but is not attached to the REST or SOAP message record. Check the Authentication type and Authentication profile fields on the message record. The auth profile is attached but the credential fields (username, password, client secret) are blank or failed to save. This is common after the Australia hardening changes, which enforced stricter validation on credential fields. The REST message method inherits auth from the parent REST message record, but the method-level auth override is set to No authentication . A Flow Designer REST Action step lost its credential reference after an upgrade or update set deployment. Resolution:

Navigate to the REST or SOAP message record (Filter Navigator → System Web Services → Outbound). Confirm the Authentication type is set to the correct value and the Authentication profile field points to the correct profile record. Open the auth profile record and confirm the credential fields are populated. For Basic Auth profiles ( sys_auth_profile_basic ), re-enter the password and save if in doubt. Use the Test related link on the REST message method to verify the Authorization header is now present in the captured request.

3.2 OAuth token expired or not refreshing ServiceNow holds a cached OAuth access token for each OAuth profile. When that token expires, ServiceNow is supposed to request a new one automatically. This fails in several scenarios:

The client secret in the oauth_entity record was not updated after the endpoint rotated it. The OAuth token URL is unreachable (network or firewall change). The token URL requires additional parameters (e.g. resource , audience ) not configured in ServiceNow. The grant type configured in ServiceNow (e.g. Client Credentials) does not match what the endpoint requires. The diagnostic signal: check sys_outbound_http_log and filter for calls to the token URL (not the API URL). If the token request call itself is returning a 401 or 400, the credential or grant type is wrong. If the token request is not appearing at all, the OAuth profile may not be correctly attached.

Common error message: OAuth token has expired or has not been retrieved. Please check your OAuth configuration and try again.

Resolution:

Navigate to Filter Navigator → System OAuth → Application Registry. Open the relevant oauth_entity record. Confirm the Client ID and Client Secret match what the endpoint's OAuth server expects. Re-enter the client secret and save if it may have been rotated. Confirm the Token URL is correct and reachable from ServiceNow. Test by running a REST message directly to the token URL with the client credentials. To force a fresh token request, delete the cached token from oauth_credential for this OAuth entity. Navigate to oauth_credential.list , filter by OAuth Entity = your entity, and delete the record. ServiceNow will request a new token on the next call.

3.3 Intermittent 401 — node-specific token cache Intermittent 401 errors that appear random — succeeding on some requests and failing on others from the same instance at the same time — are almost always caused by node-specific token caching.

Each application node maintains its own OAuth token cache. When a token is refreshed on one node, the other nodes continue using their cached (and possibly expired or invalidated) tokens until those caches expire. This means:

Requests routed to the node with the fresh token succeed. Requests routed to nodes with stale tokens fail with 401. The pattern resolves itself as all nodes eventually refresh their tokens. To confirm this is the cause: check the Source tab in the Outbound HTTP log. Note the node hostname ( System ID ) for failing calls vs. succeeding calls. If all failures come from specific nodes, node-specific caching is the cause.

Resolution:

Delete the cached token from oauth_credential for all nodes (if accessible) to force a synchronized refresh. If the intermittent pattern emerged after a client secret rotation at the endpoint, ensure the new secret is saved in the oauth_entity record immediately — this invalidates all cached tokens and forces a fresh request on every node.

3.4 403 Forbidden — credentials valid but insufficient permissions A 403 means ServiceNow successfully authenticated to the endpoint — the credentials were accepted — but the authenticated identity does not have permission to access the requested resource. This is an endpoint-side authorization issue, not a ServiceNow configuration issue.

Common causes:

The integration service account at the endpoint lacks the required role or scope for the specific API endpoint being called. The OAuth scope configured in ServiceNow does not include the permission required by the endpoint. The integration was working and then broke after an endpoint-side role or permission change. Different environments (Dev vs. Prod) have different permission configurations at the endpoint — a common reason why the same integration works in one environment and not another. Resolution:

Confirm the call is authenticated as the correct identity. Check the Request tab in the Outbound HTTP log to see which credentials were sent. Test the same request in Postman using the same credentials. If Postman also returns 403, the issue is at the endpoint — engage the endpoint team to confirm the service account permissions and required OAuth scopes. If Postman succeeds but ServiceNow returns 403, compare the request headers exactly — the OAuth scope in the ServiceNow token request may be narrower than what Postman uses.

3.5 403 Forbidden — works in Postman, fails in ServiceNow When the exact same request succeeds in Postman but returns 403 from ServiceNow, the most common cause is an IP allowlist restriction at the endpoint . The endpoint is accepting requests only from known IP addresses — your machine's IP passes, but ServiceNow's datacenter IP does not.

This pattern also appears when:

The endpoint enforces IP allowlisting and the ServiceNow instance IP range has not been added. The ServiceNow instance was moved to a different datacenter (e.g. during a migration) and the old IP range was allowlisted but not the new one. The call routes through a MID Server, and it is the MID Server's IP that needs to be allowlisted — not the ServiceNow instance IP. Resolution:

Confirm whether the endpoint enforces IP allowlisting. Check with the endpoint team. Identify the correct IP range to allowlist. For direct calls from the ServiceNow instance, refer to the ServiceNow outbound IP ranges documentation. For MID Server calls, the MID Server host's egress IP is what needs to be allowlisted. If the instance was recently migrated to a new datacenter, confirm the new IP range has been allowlisted at the endpoint.

3.6 MID Server — Unable to encrypt token When an outbound REST call is routed through a MID Server and uses OAuth, the MID Server must decrypt the OAuth credential stored in the ServiceNow instance to use it. If the encryption key on the MID Server is out of sync with the instance, decryption fails.

Error string in the Outbound HTTP log or ECC Queue:

Error executing REST request: Unable to encrypt token Decrypt error on Mid server Common triggers:

MID Server was re-installed or upgraded and the encryption key was not carried forward. The oauth_entity client secret was last saved before the current encryption key was in place. The instance was cloned and the MID Server is connecting to the cloned instance but the credential was encrypted against the source instance key. Resolution:

Navigate to Filter Navigator → System OAuth → Application Registry. Open the relevant oauth_entity record. Re-enter the client secret in the Client Secret field and save. This re-encrypts the credential with the current active encryption key, which the MID Server can now decrypt. If the error persists after re-saving, check the MID Server agent log for additional detail on the decryption failure.

3.7 Basic Auth — invalid username/password Basic Auth failures are straightforward: the endpoint rejected the username and password combination sent by ServiceNow.

Common causes:

The password in the Basic Auth profile was changed at the endpoint but not updated in ServiceNow. The Basic Auth profile record exists but the password field was not saved correctly (no error shown, but field is blank or corrupted). The integration is failing on specific nodes only after a node restart, pointing to a cached credential issue. The endpoint requires the username in a specific format (e.g. domain\username or username@domain ) that does not match what is configured. Resolution:

Open the Basic Auth Profile record ( sys_auth_profile_basic ). Re-enter the username and password and save. Test the connection using the Test related link on the REST message method. If the Request tab in sys_outbound_http_log shows an Authorization: Basic … header, decode it (Base64) to verify the username and password are correct.

3.8 Flow Designer REST Action not sending credentials Flow Designer REST Action steps occasionally stop sending the Authorization header after an upgrade, update set deployment, or scope change. This manifests as:

The REST Action worked previously and now fails with 401 with no configuration changes made. The underlying REST message record is correctly configured, but the Flow Action step is not picking up the auth profile. The error appears intermittently, correlated with flow executions. Resolution:

Open the Flow Designer action and inspect the REST step configuration. Confirm the credential field is still populated and pointing to the correct auth profile. If the credential reference was lost, re-select the auth profile on the REST step and re-publish the action. Check sys_outbound_http_log for calls made by the flow and confirm the Authorization header is present in the Request tab. If the issue is intermittent, check whether it correlates with specific nodes using the Source tab — this points to the node-specific caching pattern described in Section 3.3 .

4. MID Server — Additional Diagnostics When an outbound call routed through a MID Server returns a 401 or 403, the diagnostic path differs from a direct call in two important ways:

The token request may originate from the MID Server, not the instance. If the REST message is configured to acquire the OAuth token via MID Server, the token request call will appear in the MID Server agent log, not in sys_outbound_http_log . Check both. The MID Server must be able to decrypt the credential. See Section 3.6 for the Unable to encrypt token failure specific to MID Server calls. MID Server log search strings for auth failures:

Unable to encrypt token Decrypt error 401 (in the context of outbound REST call output) 403 oAuthClient.requestToken OAuth followed by fail or error Note — oAuthClient.requestToken via MID Server

By default, ServiceNow acquires OAuth tokens from the instance side, even for REST messages that route API calls through a MID Server. The method oAuthClient.requestToken() called from a MID Server script is a separate pattern that acquires tokens from the MID Server side. If your integration uses this pattern and tokens are failing, check the MID Server agent log directly — the token request will not appear in sys_outbound_http_log .

5. Diagnostic Steps Confirm the response code. Open sys_outbound_http_log . If the Response Status is 401 or 403, you are in the right article. If it is 0 or -1, see KB3067060 — Connection Failures & TLS Errors . Check the Authorization header. On the failing log record, open the Request tab . Is the Authorization header present and populated? If absent → Section 3.1 . If present but rejected → continue. Identify the auth type. Open the REST or SOAP message record and note the Authentication type: Basic, OAuth, API Key, or Mutual Auth. For OAuth 401s: check sys_outbound_http_log for a second log entry to the token URL. If the token request is also failing → Section 3.2 . If intermittent → check the Source tab for node pattern → Section 3.3 . For 403s: test the same request from Postman with identical credentials. If Postman also returns 403 → endpoint permissions issue → Section 3.4 . If Postman succeeds → IP allowlist issue → Section 3.5 . For MID Server calls: check the MID Server agent log for Unable to encrypt token or Decrypt error → Section 3.6 . Before opening a case, capture: Full response body and status from the failing Outbound HTTP log record. Whether the Authorization header is present in the Request tab. Auth type and auth profile name configured on the message record. Whether the same call succeeds in Postman. Whether the failure is consistent or intermittent, and if intermittent, the node hostname from the Source tab. MID Server name if applicable.

6. Resolution Summary Symptom

Auth type

Root cause

Fix

Authorization header absent in Request tab

Any

Auth profile not attached or credentials blank

Attach correct auth profile to message record; re-enter credentials

Consistent 401; token URL call also failing

OAuth 2.0

Client secret rotated at endpoint but not updated in ServiceNow

Update client secret in oauth_entity ; delete cached token from oauth_credential

Intermittent 401; failures on specific nodes

OAuth 2.0

Node-specific token cache out of sync

Delete cached oauth_credential record to force synchronized refresh on all nodes

Consistent 403; Postman also returns 403

Any

Integration identity lacks endpoint permission or OAuth scope

Engage endpoint team to grant required role or scope to integration user

403 from ServiceNow; Postman succeeds

Any

Endpoint IP allowlist blocking ServiceNow datacenter IPs

Allowlist ServiceNow instance or MID Server IP range at the endpoint

Unable to encrypt token via MID Server

OAuth 2.0

MID Server encryption key out of sync

Re-enter client secret in oauth_entity and save to re-encrypt

401; Invalid username/password combo

Basic Auth

Password changed at endpoint or not saved correctly in ServiceNow

Re-enter credentials in Basic Auth profile and save

Flow Designer REST Action intermittently missing Authorization header

Any

Auth profile reference lost on Flow Action step

Re-select auth profile on REST step; re-publish action

7. Related Articles KB0659194 - Outbound Web Services — Troubleshooting Guide KB3067060 - Outbound Web Services — Connection Failures & TLS Errors KB3067152 - Outbound Web Services — Timeouts & Slow Responses KB3067183 - Outbound Web Services — Endpoint Errors (4xx/5xx) KB0791140 — OAuth 2.0 configuration for outbound REST KB0960404 — MID Server Landing Page