OAuth & authentication in Administration

OAuth & authentication

Log users in and secure integrations the modern way.

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.

Practice challenge

+0 XPStreak ×0

Question 1 of 3

Enterprise single sign-on typically uses:

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.