Administration · Lesson

OAuth & authentication

Quick answer

Authentication decides who a user or system is. ServiceNow supports several methods; for integrations, OAuth 2.0 is the modern standard. This lesson covers the whole authentication landscape, then drills into the OAuth flows and where you configure them.

Key takeaways

Authentication options
Inbound vs outbound OAuth
Grant types
Common mistakes

Authentication decides who a user or system is. ServiceNow supports several methods; for integrations, OAuth 2.0 is the modern standard. This lesson covers the whole authentication landscape, then drills into the OAuth flows and where you configure them.

Authentication options

Local database

Usernames/passwords in sys_user. Fine for admins and service accounts, not the whole org.

SSO (SAML 2.0 / OIDC)

The norm for human users; identity lives in your IdP (Okta, Entra ID).

LDAP

Directory import and, historically, authentication.

MFA

Layered on top for stronger assurance.

OAuth 2.0

Token-based auth for API integrations, inbound and outbound.

Inbound vs outbound OAuth

Get this distinction right first, because they are configured differently:

Inbound

An external app calls into ServiceNow's APIs. Register an OAuth API endpoint for external clients.

Outbound

ServiceNow calls out to a third-party API. Register a Connect to a third-party OAuth provider entry.

Both live under the Application Registry (oauth_entity).

Grant types

Authorization code

For apps acting on behalf of a signed-in user. The secure default.

Client credentials

Server-to-server, no user context, batch integrations.

Refresh token

Exchange a long-lived token for new access tokens without re-login.

Password (ROPC)

Legacy; avoid for new integrations.

POST /oauth_token.do
  grant_type=client_credentials
  client_id=<client_id>
  client_secret=<client_secret>
--> { "access_token": "...", "expires_in": 1800 }

The returned bearer token then authorises calls to the REST API (Authorization: Bearer <token>).

Never hard-code a client secret in a browser/client app. Use the authorization-code flow for user-facing apps; reserve client-credentials for trusted server-side integrations, and store secrets in credential records, not in code.

Common mistakes

Confusing the inbound and outbound registry entries.
Hard-coding secrets in a client-side app instead of the auth-code flow.
Ignoring token expiry and never implementing refresh.
Giving the integration account admin instead of least-privilege roles.

Want to learn this properly?

Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.

See the course Ask a question

Check your understanding

Enterprise single sign-on typically uses:
- A. SAML
- B. A spreadsheet
- C. Discovery
Show answer
A. SAML
SAML delegates login to an identity provider.
OAuth secures API access without sharing:
- A. Passwords
- B. Fonts
- C. Reports
Show answer
A. Passwords
OAuth uses tokens instead of passwords.
An external app calling ServiceNow's REST API is which OAuth direction?
- A. Inbound
- B. Outbound
- C. Neither
Show answer
A. Inbound
Inbound = something calling into ServiceNow.

Frequently asked questions

Which systems are connected to OAuth & authentication?

The returned bearer token then authorises calls to the REST API (Authorization: Bearer <token>).

What tends to go wrong with OAuth & authentication?

Confusing the inbound and outbound registry entries. Hard-coding secrets in a client-side app instead of the auth-code flow. Ignoring token expiry and never implementing refresh.