ServiceNow OAuth Authorization Code Grant with Spring Security OAuth2 Client: User Context and Audit
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
20m ago
Hello Community,
We are evaluating an integration between a Java Spring application and ServiceNow using OAuth 2.0 Authorization Code Grant.
The objective is to allow an individually authenticated ServiceNow user to initiate REST API transactions through an external application while preserving the user's ServiceNow authorization context and native audit attribution.
Our proposed implementation uses:
- Spring Security OAuth2 Client
- ServiceNow as the OAuth authorization server and REST API resource server
- OAuth 2.0 Authorization Code Grant
- Enterprise SSO for interactive user authentication
- Individual-user OAuth access tokens
- ServiceNow roles and ACLs for API authorization
We have reviewed the official ServiceNow Authorization Code Grant Workflow.
We would appreciate hearing from anyone who has implemented a similar integration.
Specifically:
Spring Security integration: Have you successfully used Spring Security OAuth2 Client with ServiceNow's inbound Authorization Code Grant?
OAuth versus OIDC: Did you configure ServiceNow as a standard OAuth 2.0 provider using its authorization and token endpoints, without requiring OpenID Connect discovery or ID tokens?
PKCE: Have you implemented PKCE with a confidential Spring Security OAuth client against ServiceNow? Were any additional configuration steps necessary?
User authorization: When an access token obtained through the individual-user Authorization Code flow is used for REST API operations, does ServiceNow evaluate the authenticated user's roles and ACLs as expected?
Native audit attribution: For REST API record creation and updates, do sys_created_by, sys_updated_by, and the native audit/history records reflect the authenticated user?
Implementation considerations: Were there any unexpected issues with callback configuration, refresh-token handling, user-session association, or authorization-code processing?
We understand that Authorization Code requires interactive user authorization and are not attempting to bypass that requirement.
We are interested in standards-based, supported implementations rather than custom authentication or user-impersonation mechanisms.
Any examples, documentation references, or lessons learned would be appreciated.
Thank you!
