OAuth 2.0
Quick answer
Set up OAuth providers and clients, choose the right grant, and rotate secrets safely.
Key takeaways
- Inbound uses an application registry, outbound uses a provider record
- Prefer JWT or client credentials for system to system
- Keep secrets in credentials, not in code
- Plan rotation and token lifetime up front
Inbound versus outbound
Inbound OAuth lets an external system authenticate to ServiceNow: create an OAuth application registry entry of type endpoint for client, and the client uses client id, secret and a user grant. Outbound OAuth lets ServiceNow call a protected API, using a provider entry with token and authorisation URLs.
Choosing a grant
Authorisation code when a user identity is involved. Client credentials or JWT bearer for system to system, which is what most integrations need. Password grant still exists and should be avoided for new work.
Operating it
Tokens and secrets need lifecycle management.
- Store secrets in credential records, never in a script or property
- Set token lifetimes deliberately, long lived tokens are a risk
- Plan rotation before go live and document who owns the credential
- Watch for clock skew, JWT assertions fail when the instance and provider disagree on time
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which grant suits a nightly server to server sync?
- A. Authorisation code
- B. Client credentials or JWT
- C. Implicit
- D. Password
Show answer
B. Client credentials or JWT
No user is present, so a system grant is correct.
Where should the client secret be stored?
- A. A system property
- B. A credential record
- C. The script include
- D. The connection name
Show answer
B. A credential record
Credential records are encrypted and referenced by alias.