Inbound Basic Auth deprecation - which OAuth/federated patterns are customers standardizing on?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hello Community,
We're beginning early planning for ServiceNow's announced deprecation of Basic Authentication for inbound integrations and are reviewing the target authentication architecture for a mixed portfolio of existing integrations.
Our current inventory includes backend/system integrations, user-attributed application activity, and ServiceNow platform identities such as MID Servers.
ServiceNow's current inbound authentication documentation includes several modern options, including:
- OAuth 2.0 Client Credentials
- OAuth 2.0 Authorization Code
- JWT Bearer
- Third-party OIDC / ID Token
- Certificate-based mutual authentication (mTLS)
Rather than allowing every legacy integration to independently select a replacement, we're considering establishing a small set of preferred ServiceNow inbound-authentication patterns.
Our preliminary model is:
1. Backend machine-to-machine integrations:
OAuth Client Credentials as a default pattern, with JWT Bearer considered where signed key-based authentication is preferable.
2. Applications acting on behalf of individual users:
Authorization Code / appropriate user-delegated OAuth flow.
3. Enterprise identity-provider integrations:
Third-party OIDC / federated ID token where the architecture supports it.
4. MID Servers:
Follow ServiceNow's platform-specific migration path rather than treating MID authentication as a conventional custom integration.
For customers and architects already working through this:
- Have you standardized on a preferred inbound authentication pattern?
- Is Client Credentials your normal machine-to-machine baseline?
- Where are you preferring JWT Bearer over Client Credentials?
- Are you using third-party OIDC tokens from Entra ID or another corporate IdP for inbound ServiceNow APIs?
- Where has mTLS proven preferable to token-based authentication?
- Are there ServiceNow product/API limitations that prevented you from using your preferred pattern?
- How are you testing and governing these patterns across non-production and production instances?
I'm particularly interested in lessons from real implementations rather than simply confirming that each authentication type is technically available.
Thanks,
Jeff
0 REPLIES 0
