docs / auth
The server uses MCP-spec OAuth 2.0 with PKCE to authenticate MCP clients, delegating to ServiceNow for user identity. Every tool call executes as the authenticated user — there are no shared service accounts.
- MCP client discovers OAuth metadata via
/.well-known/oauth-authorization-server - Client registers dynamically via
POST /register(getsclient_id+client_secret) - Client sends user to
GET /authorizewith PKCEcode_challenge - Server redirects user to ServiceNow for login/consent
- ServiceNow redirects back to
/oauth/sn-callbackwith an authorization code - Server exchanges the SN code for SN tokens, stores them, and generates our own authorization code
- Server redirects back to the MCP client's
redirect_uriwith our code - Client exchanges our code via
POST /token(with PKCEcode_verifier) - Server returns an opaque MCP access token + refresh token
- Client sends
Authorization: Bearer <token>on every/mcprequest - Tool calls resolve user from the bearer token → ServiceNow API calls use the user's SN access token
| Guide | Description |
|---|---|
| OAuth Flow | Authorization Code flow with CSRF protection |
| Token Storage | AES-256-GCM encryption, StoredToken shape, Redis keys |
| Token Refresh | Transparent refresh with distributed lock |
- MCP-spec OAuth: Standard discovery, PKCE, dynamic client registration — MCP clients handle auth natively.
- Per-user isolation: Each user's tokens are stored separately. One user cannot access another's credentials.
- Encryption at rest: ServiceNow tokens are encrypted with AES-256-GCM before being written to Redis.
- Two-layer tokens: MCP clients get opaque access/refresh tokens; these map to ServiceNow tokens stored in Redis.
- Automatic refresh: ServiceNow access tokens are refreshed transparently when they expire (with a 60-second buffer).
- Bearer auth: Every
/mcprequest requiresAuthorization: Bearer— no more session-based auth.
See also: ServiceNow OAuth Setup · Redis Schema · Security Overview