ServiceNow Authentication Methods — A Visual Guide for M365 Copilot Connectors
April 2026·Microsoft 365 · ServiceNow · Copilot Connectors·✓ Fact-checked against Microsoft Learn
If you have ever stared at the ServiceNow connector setup screen wondering
"Which authentication should I pick?" — this post is for you. All four methods are explained with architecture flow diagrams, setup steps, a side-by-side security comparison, and a clear decision guide.
This guide covers all three ServiceNow connectors for Microsoft 365 Copilot:
Knowledge,
Catalog, and
Tickets. The four auth methods work the same way across all three — but there are important per-connector differences in required roles and permissions, highlighted throughout.
Sources (verified April 2026): ServiceNow Knowledge,
ServiceNow Catalog, and
ServiceNow Tickets connector documentation on Microsoft Learn.
✓ Federated Auth — Recommended⚠ Basic Auth — Dev/Test Only◈ ServiceNow OAuth 2.0◈ Entra ID OpenID Connect
1. What are we actually connecting?
Before diving into authentication methods, here is the big picture. There are three ServiceNow connectors available in the Microsoft 365 admin center, each bringing different content into M365 Copilot experiences:
- ServiceNow Knowledge — indexes knowledge base articles
- ServiceNow Catalog — indexes service catalog items
- ServiceNow Tickets — indexes ticket records (incidents, problems, changes)
Source
Microsoft 365
Copilot + Admin Center
→config
Bridge
Copilot Connector
Crawls + indexes content
→auth + crawl
Target
ServiceNow
KB · Catalog · Tickets
All three connectors support the same four authentication methods. However, the required roles and permissions differ per connector — these differences are called out clearly in each method section below.
2. Method 1 — Federated Auth (Recommended)
This is the gold standard. Instead of storing a password or secret anywhere, it uses a Microsoft-owned OIDC application to issue a token that ServiceNow validates. No credentials are ever stored in the connector config, and there is nothing to manually rotate.
Architecture flow
No password or secret is ever stored
M365 Connector
Needs to crawl ServiceNow
1. request token
→
2. JWT returned
←
Microsoft Entra ID
App ID: 933838e2…
3. present JWT
→
4. access granted
←
ServiceNow
OIDC provider validates token
Setup steps
1
Get the Service Principal Object ID. Run the following PowerShell command:
Get-AzADServicePrincipal -ApplicationId "933838e2-bec1-440f-a634-9363c82e5b6d"
Alternatively, query the Microsoft Graph API. Copy the Id value from the output.
2
Create the OIDC provider in ServiceNow. Go to
All → System OAuth → Application Registry → New. Set:
- Client ID:
933838e2-bec1-440f-a634-9363c82e5b6d - OIDC Metadata URL:
https://login.microsoftonline.com/<tenantId>/v2.0/.well-known/openid-configuration - User Claim:
sub or oid | User Field: User ID - Auth Scope:
useraccount — enable "Allow access only to APIs in selected scope"
3
Create the ServiceNow integration user. User ID = Service Principal Object ID from Step 1, Identity Type = Machine, Active = checked. Assign roles: catalog_admin, user_criteria_admin, user_admin.
4
In the M365 admin center, select Federated Auth as the authentication method and provide your ServiceNow instance URL.
✓When to use it: Any production environment where your organisation uses Microsoft 365 / Entra ID. This is the only method where there is nothing to rotate, nothing to leak, and nothing to expire unexpectedly. Microsoft's explicit recommendation.
⚡ Connector differences — Federated Auth
The Federated Auth setup steps (App ID, OIDC provider, integration user) are
identical across all three connectors — Knowledge, Catalog, and Tickets. The same first-party App ID
933838e2-bec1-440f-a634-9363c82e5b6d is used in all cases. The integration user always receives the same three roles:
catalog_admin,
user_criteria_admin,
user_admin.
3. Method 2 — Basic Authentication
The simplest method — and the most dangerous for production. You type a username and password into the connector setup and they are stored in plain form. No token layer, no MFA enforcement, no Entra ID audit trail.
Architecture flow
Credentials stored directly in connector config
M365 Connector
Stores: username + password
username + password
→
access granted
←
ServiceNow
Account with knowledge role
Setup steps
1
Create or identify a ServiceNow service account with at minimum the knowledge role.
2
Enter the username and password directly in the connector setup in the M365 admin center. No further steps required.
Risks and limitations
No MFA supportMulti-factor authentication cannot be enforced on this flow.
Password stored in configVisible to anyone with admin access to M365 settings.
No Entra ID audit trailOnly ServiceNow-side logs are available.
Manual rotation requiredChanging the password breaks the connector until updated.
⚠When to use it: Quick POC or dev/test environments where speed matters more than security. Never in production — credentials are stored in plain form in the connector config.
⚡ Connector differences — Basic Auth
The required ServiceNow account role differs per connector:
- Knowledge connector: account must have the
knowledge role - Catalog connector: account must have the
catalog role - Tickets connector: account must have read access to the
task and sys_user tables (not a named role)
4. Method 3 — ServiceNow OAuth 2.0
A meaningful step up from Basic Auth. ServiceNow issues its own OAuth access tokens — no password travels over the wire, just a client ID and secret that exchange for time-limited tokens. This method does not require Azure or Entra ID.
Architecture flow
Token-based — no password on the wire
M365 Connector
Holds: client ID + secret
1. send client ID + secret
→
2. access token returned
←
ServiceNow OAuth Server
App Registry endpoint
3. use access token
→
4. data returned
←
ServiceNow REST API
KB / Catalog data
OAuth endpoint configuration — required fields
| Field | Recommended value |
|---|
| Redirect URL (M365 Enterprise) | https://gcs.office.com/v1.0/admin/oauth/callback |
| Redirect URL (M365 Government) | https://gcsgcc.office.com/v1.0/admin/oauth/callback |
| Refresh token lifespan | 31,536,000 seconds (1 year) |
| Access token lifespan | 43,200 seconds (12 hours) |
| Auth Scope | useraccount |
◈When to use it: Your organisation is not Azure-centric, or you cannot configure OIDC in ServiceNow but need better security than Basic Auth. Also suitable as a transitional option while migrating to Federated Auth. The client secret must be managed manually — treat it like a password and rotate it on a schedule.
⚡ Connector differences — OAuth 2.0
The OAuth endpoint configuration (redirect URL, token lifespans, Auth Scope) is
identical across all three connectors. However, the crawl account permissions after the token exchange differ:
- Knowledge connector: crawl account needs the
knowledge role - Catalog connector: crawl account needs the
catalog role - Tickets connector: crawl account needs read access to the
task and sys_user tables
5. Method 4 — Microsoft Entra ID OpenID Connect
Federated Auth's sibling — same OIDC protocol, same token-based approach, but instead of using Microsoft's first-party app, you register your own app in Entra ID. More control and ownership, more administrative responsibility.
Architecture flow
Your custom app registration — full Entra ID security model
Your App Registration
in Microsoft Entra ID
1. authenticate w/ secret
→
2. JWT issued
←
Microsoft Entra ID
Issues JWT for your app
3. present JWT
→
4. access granted
←
ServiceNow
OIDC provider validates token
Setup steps
1
Register a new single-tenant app in Microsoft Entra ID. A redirect URI is not required.
2
Copy the Application (client) ID and Directory (tenant) ID from the app overview page.
3
Create a client secret. Go to Manage → Certificates and secrets → New client secret. Save the value securely — you will not be able to see it again.
4
Get the Service Principal Object ID via PowerShell: Get-AzADServicePrincipal -ApplicationId "<your-app-id>"
5
Register an OIDC provider in ServiceNow. Use your Application (client) ID as Client ID, OIDC Metadata URL = https://login.microsoftonline.com/<tenantId>/.well-known/openid-configuration, User Claim = sub, Auth Scope = useraccount.
6
Create a ServiceNow user with User ID = Service Principal Object ID. Assign the knowledge role. Do not enable "Assignment required" on the enterprise application in Entra ID.
Key difference vs Federated Auth: Federated Auth uses Microsoft's first-party app — no secret is needed. This method uses your own custom app registration, which requires managing a client secret. The OIDC security model is the same; the difference is ownership and maintenance responsibility.
◈When to use it: Your security or compliance team requires owning the app registration for auditing purposes, or you need custom Conditional Access policies scoped to this specific integration. Provides the same OIDC security level as Federated Auth, but you are responsible for the client secret lifecycle.
⚡ Connector differences — Entra ID OIDC
The app registration steps and OIDC provider configuration are
identical across all three connectors. The role assigned to the ServiceNow user differs:
- Knowledge connector: assign the
knowledge role to the ServiceNow user - Catalog connector: assign the
catalog role to the ServiceNow user - Tickets connector: assign the
itil role — this provides read/write/create access to core ITSM tables (Incident, Problem, Change)
In all three cases: do
not enable "Assignment required" on the enterprise application in Entra ID.
6. Connector differences — Knowledge vs Catalog vs Tickets
The four auth methods work identically in terms of protocol, token handling, and OIDC/OAuth mechanics. The differences are purely in what roles or table permissions the ServiceNow account needs. Here is the full picture in one place.
Basic Auth — required account permission
| Connector | ServiceNow account needs |
|---|
| Knowledge | knowledge role |
| Catalog | catalog role |
| Tickets | Read access to task and sys_user tables |
OAuth 2.0 — crawl account permission (after token exchange)
| Connector | Crawl account needs |
|---|
| Knowledge | knowledge role |
| Catalog | catalog role |
| Tickets | Read access to task and sys_user tables |
Entra ID OIDC — ServiceNow user role
| Connector | Role assigned to ServiceNow OIDC user |
|---|
| Knowledge | knowledge role |
| Catalog | catalog role |
| Tickets | itil role (read/write/create on Incident, Problem, Change tables) |
Federated Auth — integration user roles
| Connector | Roles assigned to integration user |
|---|
| Knowledge | catalog_admin, user_criteria_admin, user_admin |
| Catalog | catalog_admin, user_criteria_admin, user_admin |
| Tickets | catalog_admin, user_criteria_admin, user_admin |
Tickets connector — unique access permissions restriction:
The Tickets connector does not support the "Everyone" access permission option. You must select "Only people with access to this data source" and configure per-table access rules using user fields (e.g. Assigned to, Opened by, Closed by) or roles (e.g. itil, asset, admin). This restriction does not apply to the Knowledge or Catalog connectors.
7. Side-by-side security comparison
Here is how the four methods compare on the dimensions that matter most for a production deployment.
| Security dimension | Federated Auth ★ | Basic Auth | OAuth 2.0 | Entra ID OIDC |
|---|
| No password stored | Yes | No | Yes | Yes |
| No secret rotation needed | Yes | Manual | Manual | Manual |
| MFA / Conditional Access | Full | None | Partial | Full |
| Entra ID audit logs | Full | None | None | Full |
| Works without Azure / Entra ID | No | Yes | Yes | No |
| Token-based (no password on wire) | Yes | No | Yes | Yes |
| Setup complexity | Medium (3 steps) | Low (2 steps) | Medium (4–5 steps) | Medium-high (6 steps) |
| Recommended for production | Yes ★ | No | With caveats | Yes |
8. Decision guide — which one should YOU pick?
Follow this simple decision path to find the right method for your environment.
Setting up a ServiceNow connector?
Is this a production environment?
No (dev / test)
Basic Auth
Quick to set up, not secure
Yes (production)
Do you use Microsoft 365 / Entra ID?
No
ServiceNow OAuth 2.0
Token-based, no Azure needed
Yes
Need your own app registration? (compliance / audit)
No
Federated Auth ★
Best choice — no secrets
Yes
Entra ID OIDC
Full control, manage secret
9. Quick-reference cards
Federated Auth
RecommendedProtocolOIDC (Microsoft first-party)
Secret needed?None
Setup complexityMedium (3 steps)
Requires Azure?Yes
MFA supportFull
Audit logsFull (Entra ID)
Best choice for any org on M365. No credentials to manage, no rotation, full Entra ID audit logs. Microsoft's explicit recommendation.
Basic Authentication
Dev/Test OnlyProtocolUsername + password
Secret needed?Password stored
Setup complexityLow (2 steps)
Requires Azure?No
MFA supportNone
Audit logsServiceNow only
Only for quick POCs. Never in production — the password is stored in plain form in the connector config.
ServiceNow OAuth 2.0
Good FallbackProtocolOAuth 2.0 token exchange
Secret needed?Client ID + secret
Setup complexityMedium (4–5 steps)
Requires Azure?No
MFA supportPartial
Audit logsServiceNow only
Use when Azure is not available or during migration from Basic Auth. Tokens expire; no password on the wire. Client secret requires manual rotation.
Entra ID OIDC
Custom ControlProtocolOIDC (your own app)
Secret needed?Client secret (yours)
Setup complexityMedium-high (6 steps)
Requires Azure?Yes
MFA supportFull
Audit logsFull (Entra ID)
Choose when compliance requires owning the app registration. Same OIDC security level as Federated Auth, but you manage the client secret lifecycle.
Conclusion
If you are on Microsoft 365, use Federated Auth — full stop. It is the only method where there is genuinely nothing to rotate, nothing to leak, and nothing to expire unexpectedly. Microsoft designed it specifically to eliminate the credential-management headache for connector deployments.
If Azure is not in the picture, ServiceNow OAuth 2.0 is your next-best option — token-based, no password on the wire, works without any Azure dependency.
If your security team requires owning the app registration in Entra ID, Entra ID OIDC gives you that control while keeping the full OIDC security model intact.
Save Basic Auth for the few minutes you need to test something on a dev instance — and never let it anywhere near production data.
No comments:
Post a Comment