Integrations

ServiceNow Okta Integration Guide

intermediateSAML 2.0 for SSO authentication, OAuth 2.0 Bearer Token for SCIM provisioning API callsOkta

ServiceNow Okta integration provides comprehensive identity and access management by enabling single sign-on (SSO), automated user provisioning, and role synchronization between Okta and ServiceNow. This integration solves critical business problems around user lifecycle management, security compliance, and administrative overhead reduction for IT teams managing enterprise access across both platforms. The integration supports bi-directional data flows including user authentication via SAML 2.0 or OIDC, inbound user provisioning through SCIM 2.0, and outbound ServiceNow user status updates to Okta. Primary automation patterns include real-time user provisioning triggered by Okta user lifecycle events, role mapping based on Okta group memberships, and automated deprovisioning when users are deactivated in Okta, with configuration managed through ServiceNow's Identity Provider and User Administration modules.

Prerequisites

  • ServiceNow Tokyo release or later with Multi-Provider SSO plugin (com.glide.sso.multi_provider) activated
  • Okta administrator access with ability to create SAML/OIDC applications and API tokens
  • ServiceNow Integration Hub Professional license for Okta Workflows spoke usage
  • SCIM provisioning feature enabled in Okta (available in Okta Workforce Identity plans)
  • ServiceNow user_admin or security_admin role for SSO configuration
  • Valid SSL certificates configured on ServiceNow instance for SAML assertion validation
  • Network connectivity between Okta and ServiceNow instance (no MID Server required for cloud instances)

Architecture Overview

The integration leverages multiple ServiceNow components including the built-in SAML 2.0 Identity Provider framework, SCIM 2.0 inbound REST endpoints, and optionally the Integration Hub Okta Workflows spoke for advanced automation scenarios. Authentication is established through SAML assertion validation using X.509 certificates stored in ServiceNow's Identity Provider records, while SCIM provisioning uses Okta API bearer tokens stored in Connection & Credential Alias records. Data flows bidirectionally with inbound SAML assertions and SCIM user provisioning requests from Okta, plus optional outbound API calls to Okta using RESTMessageV2 or the Okta Workflows spoke for user status updates and group synchronization. No MID Server is required for cloud-to-cloud integration, but the architecture supports high-volume user provisioning with Okta's rate limits of 600 requests per minute for SCIM endpoints. ServiceNow processes inbound SCIM requests through scripted REST APIs and Transform Maps, automatically creating or updating user records and role assignments based on Okta group mappings configured in Identity Provider Group Mappings.

Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Implementation Steps

1

Configure ServiceNow as SAML Service Provider

Navigate to System Security > SSO > Identity Providers and create a new Identity Provider record with Type set to 'SAML'. Set the Name to 'Okta SSO' and enable 'Active' checkbox. Configure the Identity Provider URL using your Okta domain format: https://your-domain.okta.com/app/servicenow/exk.../sso/saml, and set the Certificate field to store Okta's X.509 signing certificate. In the Advanced tab, ensure 'Auto Provision Users' is checked if you want SSO-triggered user creation, and configure attribute mappings for email, first_name, and last_name fields.

2

Create Okta SAML application for ServiceNow

In Okta Admin Console, navigate to Applications > Applications and click 'Create App Integration', selecting SAML 2.0. Configure the Single Sign-On URL as https://your-instance.service-now.com/navpage.do and set Audience URI to https://your-instance.service-now.com. In Attribute Statements section, map 'email' to user.email, 'first_name' to user.firstName, and 'last_name' to user.lastName. Download the X.509 certificate from the Sign On tab and copy the Identity Provider metadata URL for ServiceNow configuration.

3

Enable SCIM provisioning in ServiceNow

Navigate to System Web Services > Scripted REST APIs and verify the 'SCIM API' is active, or activate the SCIM plugin (com.glide.scim) if not present. Go to System OAuth > Application Registry and create an OAuth API endpoint for external clients, noting the Client ID and Client Secret. Configure SCIM endpoint authentication by navigating to User Administration > User Provisioning and enabling 'SCIM Provisioning' with proper authentication settings. Set up inbound email domain validation to ensure provisioned users have valid email addresses matching your organization's domains.

4

Configure Okta SCIM provisioning to ServiceNow

In the Okta ServiceNow application, navigate to the Provisioning tab and click Configure API Integration. Enter the SCIM Base URL as https://your-instance.service-now.com/api/now/scim/v2 and provide the OAuth credentials created in ServiceNow. Test the API connection and enable provisioning features like Create Users, Update User Attributes, and Deactivate Users. Configure attribute mappings to ensure Okta user properties map correctly to ServiceNow user fields, particularly email, userName, and displayName attributes.

5

Set up Okta group to ServiceNow role mappings

Navigate to System Security > SSO > Identity Provider Group Mappings in ServiceNow and create mapping records linking Okta groups to ServiceNow roles. For each mapping, set the Identity Provider to your Okta provider, enter the exact Okta group name in the External Group field, and select the corresponding ServiceNow role. Enable 'Auto Create' to automatically assign roles during user provisioning, and configure 'Remove on Update' to dynamically adjust role assignments when Okta group memberships change. Test mappings by provisioning a test user with specific Okta group memberships and verifying role assignments in ServiceNow.

ServiceNow Script
// Business Rule to log role assignments during SCIM provisioning
(function executeRule(current, previous) {
    if (current.isNewRecord() || current.roles.changes()) {
        gs.info('SCIM Role Assignment: User ' + current.user_name + ' assigned roles: ' + current.roles);
        // Optional: Call Okta API to update user profile
        var rm = new sn_ws.RESTMessageV2('Okta User API', 'Update User');
        rm.setStringParameterNoEscape('user_id', current.sys_id);
        rm.setRequestBody(JSON.stringify({profile: {serviceNowRoles: current.roles.toString()}}));
        var response = rm.execute();
    }
})(current, previous);
6

Configure Okta Workflows spoke for advanced automation

Navigate to Process Automation > Flow Designer and install the Okta Workflows spoke from the ServiceNow Store if advanced bidirectional sync is required. Create a Connection Alias under Connections & Credentials with Connection Type 'Okta Workflows' and configure the Okta domain and API token with appropriate scopes (okta.users.manage, okta.groups.read). Build flows using Okta spoke actions like 'Get User', 'Update User', and 'List Groups' to sync ServiceNow user changes back to Okta, triggered by ServiceNow user record updates or role changes. Test the spoke connection and create error handling flows for API failures or rate limiting scenarios.

ServiceNow Script
// Flow Designer script step to sync ServiceNow role changes to Okta
(function execute(inputs, outputs) {
    try {
        var userId = inputs.user_sys_id;
        var roles = inputs.user_roles.split(',');
        
        // Call Okta Workflows spoke to update user profile
        var oktaResponse = sn_fd.FlowAPI.getRunner()
            .name('Okta Update User Profile')
            .inBackground()
            .withInputs({
                'okta_user_id': inputs.okta_user_id,
                'servicenow_roles': roles.join(';')
            })
            .run();
            
        outputs.success = true;
        outputs.response = oktaResponse;
    } catch (error) {
        outputs.success = false;
        outputs.error_message = error.message;
        gs.error('Okta sync failed: ' + error.message);
    }
})(inputs, outputs);
7

Test end-to-end integration and user lifecycle

Create a test user in Okta and assign them to groups mapped to ServiceNow roles, then verify the user is automatically provisioned in ServiceNow with correct role assignments. Test SSO by accessing ServiceNow through Okta's chiclet and confirm seamless authentication without password prompts. Validate deprovisioning by deactivating the test user in Okta and ensuring the ServiceNow user record is properly deactivated through SCIM. Monitor System Logs > All for any SAML assertion validation errors or SCIM provisioning failures, and check the Identity Provider logs for detailed authentication flow information.

ServiceNow Script
// Script to validate SCIM provisioned user attributes
var testUser = new GlideRecord('sys_user');
testUser.addQuery('email', 'test.user@yourcompany.com');
testUser.addQuery('source', 'scim');
testUser.query();
if (testUser.next()) {
    gs.info('SCIM User Found: ' + testUser.user_name);
    gs.info('Roles: ' + testUser.roles);
    gs.info('Active: ' + testUser.active);
    gs.info('Last Login: ' + testUser.last_login_time);
    // Validate Okta group mappings
    var grMember = new GlideRecord('sys_user_has_role');
    grMember.addQuery('user', testUser.sys_id);
    grMember.query();
    while (grMember.next()) {
        gs.info('Assigned Role: ' + grMember.role.name);
    }
} else {
    gs.error('SCIM provisioned test user not found');
}
8

Configure monitoring and maintenance procedures

Set up ServiceNow Event Rules to monitor SCIM provisioning failures and SAML authentication errors, creating incidents for investigation when integration issues occur. Navigate to System Diagnostics > Stats and configure performance counters for SCIM API calls and SAML assertion processing to track integration health. Create scheduled jobs to periodically validate certificate expiration dates in Identity Provider records and sync user status between Okta and ServiceNow for any drift detection. Document troubleshooting procedures and establish alerting for Okta service disruptions that might affect ServiceNow user access.

ServiceNow Script
// Scheduled job to monitor SCIM provisioning health
var scimStats = new GlideAggregate('sys_log');
scimStats.addQuery('level', 'error');
scimStats.addQuery('source', 'LIKE', '%scim%');
scimStats.addQuery('sys_created_on', '>', gs.hoursAgoStart(24));
scimStats.addAggregate('COUNT');
scimStats.query();
if (scimStats.next() && scimStats.getAggregate('COUNT') > 10) {
    // Create incident for SCIM integration issues
    var incident = new GlideRecord('incident');
    incident.initialize();
    incident.short_description = 'High SCIM provisioning errors detected';
    incident.description = 'More than 10 SCIM errors in the last 24 hours. Review Okta integration health.';
    incident.priority = 2;
    incident.assignment_group = 'Identity Management';
    incident.insert();
    gs.eventQueue('scim.health.alert', incident, gs.getUserID(), gs.getUserName());
}

Common Use Cases

Automated employee onboarding with role assignment

When HR adds a new employee to Okta and assigns them to department-specific groups, SCIM automatically provisions the user in ServiceNow with appropriate roles based on group mappings. The user receives immediate access to ServiceNow modules relevant to their job function without manual intervention from IT administrators. This reduces onboarding time from hours to minutes and ensures consistent access provisioning across the organization. Role assignments are dynamically updated if the employee changes departments or gains additional responsibilities in Okta.

Contractor and temporary user lifecycle management

External contractors added to Okta with time-limited access are automatically provisioned in ServiceNow with restricted roles and expiration dates synced through SCIM attributes. When contractor assignments end, Okta deactivation immediately triggers ServiceNow account deactivation, ensuring no orphaned access remains. This use case particularly benefits project-based organizations that frequently onboard and offboard external users. Integration logs provide complete audit trails for compliance reporting on contractor access patterns.

Department reorganization and bulk role updates

During organizational restructuring, IT administrators update Okta group memberships for affected employees, and ServiceNow roles are automatically adjusted through group mapping synchronization. Users seamlessly transition to new access levels without service interruption or manual ticket processing. The integration handles complex scenarios where users move between multiple groups simultaneously, applying additive role assignments where configured. Audit logs capture all role changes with timestamps and source attribution for compliance documentation.

Service desk agent provisioning with tiered access

New service desk agents added to Okta groups like 'ServiceDesk-L1' or 'ServiceDesk-L2' are automatically provisioned with corresponding ServiceNow roles such as 'itil' or 'incident_manager' based on their support tier. Group hierarchy in Okta translates to progressive role assignments in ServiceNow, ensuring agents have appropriate access to incident queues and knowledge bases. When agents are promoted or change teams, Okta group updates automatically adjust their ServiceNow permissions. This eliminates manual role management overhead and reduces access-related service desk tickets.

Emergency access provisioning and revocation

During security incidents or system emergencies, administrators can rapidly grant elevated ServiceNow access by adding users to emergency Okta groups, triggering immediate role provisioning through SCIM. Emergency access groups are configured with time-based expiration policies in Okta, automatically removing elevated permissions after defined periods. Integration flows can notify security teams when emergency access is granted or expires, maintaining security oversight. This use case supports incident response scenarios where rapid access changes are critical for business continuity.

Troubleshooting

SCIM user provisioning fails with 409 conflict error when creating users

Check for existing ServiceNow users with the same email address or user_name by querying the sys_user table. Navigate to User Administration > Users and search for duplicate records, including inactive users that might conflict with new provisioning attempts. Modify the Okta SCIM attribute mapping to use a unique identifier format, or enable 'Update User Attributes' in Okta provisioning settings to handle existing user scenarios. Review SCIM Transform Maps in ServiceNow to ensure proper conflict resolution logic handles duplicate email addresses gracefully.

SAML authentication redirects to ServiceNow login page instead of completing SSO

Verify the Identity Provider record in ServiceNow has the correct metadata URL and X.509 certificate from Okta by comparing certificate fingerprints in both systems. Navigate to System Logs > All and filter for 'saml' to identify assertion validation failures or attribute mapping errors. Check that the Okta SAML application's Single Sign-On URL exactly matches your ServiceNow instance URL format, and ensure the NameID format is set to 'EmailAddress' in Okta application settings. Test SAML response validation using browser developer tools to capture assertion payload and verify attribute mappings.

Okta group mappings not creating ServiceNow role assignments during provisioning

Navigate to System Security > SSO > Identity Provider Group Mappings and verify that External Group names exactly match Okta group names with correct case sensitivity. Check that the Identity Provider field references the correct Okta provider record, and ensure 'Auto Create' is enabled for dynamic role assignment. Review SCIM payload logs in System Web Services > REST API logs to confirm Okta is sending group membership information in provisioning requests. Test group mappings by manually running the Identity Provider Group Mapping script include to validate mapping logic execution.

Integration Hub Okta spoke actions return 401 unauthorized errors

Verify the Connection Alias credential contains a valid Okta API token with required scopes by testing the token directly against Okta's API using tools like Postman. Navigate to Connections & Credentials > Connection Aliases and update the credential with a fresh API token generated from Okta's Security > API page. Check that the Okta domain URL in the connection is formatted correctly without trailing slashes, and ensure the API token has 'okta.users.manage' and 'okta.groups.read' scopes assigned. Review Flow Designer execution logs for specific error details that might indicate rate limiting or permission scope issues.

SCIM deprovisioning from Okta not deactivating ServiceNow users

Check Okta application provisioning settings to ensure 'Deactivate Users' is enabled and configured to send SCIM PATCH requests for user status changes. Navigate to System Web Services > Scripted REST APIs and review SCIM API logs for incoming deactivation requests, verifying that Okta is sending proper PATCH operations with active=false. Examine SCIM Transform Maps to ensure user deactivation logic properly sets the 'active' field to false rather than deleting user records. Test deactivation by monitoring System Logs during Okta user suspension to confirm ServiceNow receives and processes the status change correctly.

Certificate validation errors causing SAML authentication failures

Navigate to System Security > SSO > Identity Providers and verify the stored X.509 certificate matches Okta's current signing certificate by downloading the latest certificate from Okta's SAML application metadata. Check certificate expiration dates and renewal requirements, as expired certificates will cause all SAML assertions to fail validation. Use ServiceNow's Certificate Management application to upload and validate certificate chains if intermediate certificates are required. Review System Logs for specific certificate validation error messages that indicate whether the issue is expiration, chain validation, or signature mismatch problems.

Pro Tips

  • Implement custom SCIM Transform Maps to enrich user provisioning with additional ServiceNow-specific attributes like location, department, and cost center based on Okta user profile extensions. This eliminates manual data entry and ensures consistent user record completeness across systems while supporting advanced reporting and organizational analytics.
  • Configure ServiceNow Business Rules on the sys_user table to trigger outbound Integration Hub flows when user roles change, automatically updating Okta user profiles with ServiceNow role information for bidirectional synchronization. This creates a comprehensive identity governance model where both systems maintain current user access state information.
  • Set up proactive monitoring using ServiceNow Event Management to track SCIM API response times and SAML assertion processing latency, creating early warning alerts before user experience is impacted. Configure dashboard widgets displaying integration health metrics and provision success rates for ongoing operational visibility.
  • Leverage Okta's SCIM filtering capabilities to provision only specific user populations to ServiceNow based on user attributes or group memberships, reducing license consumption and improving security posture. Create separate Okta applications with different SCIM configurations for employee versus contractor populations with distinct role mapping strategies.
  • Implement ServiceNow scheduled jobs to periodically reconcile user status between Okta and ServiceNow, identifying and correcting any synchronization drift that might occur during system maintenance windows or network disruptions. Include automated remediation logic that can re-sync individual user records without full reprovisioning cycles.
  • Configure custom certificate rotation workflows using ServiceNow's Certificate Management features to proactively update SAML signing certificates before expiration, preventing authentication outages. Create calendar reminders and approval workflows for certificate updates that can be tested in sub-production environments first.

Known Limitations

  • SCIM provisioning is subject to Okta's rate limiting of 600 requests per minute, which can impact bulk user operations during large organizational changes or initial deployment phases. ServiceNow cannot override these limits, so large user populations may require staggered provisioning approaches or manual batch processing during peak sync periods.
  • ServiceNow's out-of-box SCIM implementation supports only basic user attributes and group memberships, requiring custom development for complex organizational hierarchies or custom user fields. Advanced use cases like manager relationships, multi-value attributes, or complex approval workflows need additional scripting and Transform Map customization beyond standard configuration.
  • The Integration Hub Okta spoke requires Professional licensing and has limited pre-built actions compared to full REST API capabilities, potentially necessitating custom RESTMessageV2 implementations for advanced Okta features. Spoke actions also inherit Flow Designer's execution limitations around long-running processes and complex error handling scenarios.
  • SAML session management between Okta and ServiceNow can create inconsistent logout experiences, where users logged out of one system may remain authenticated in the other until session timeout occurs. This behavior varies based on browser settings and can impact security policies requiring immediate access revocation.
  • Certificate management for SAML integration requires manual intervention for renewals and updates, with no automated certificate rotation capabilities in the standard ServiceNow SAML framework. Organizations must implement custom monitoring and renewal processes to prevent authentication outages from expired certificates.

Frequently Asked Questions

Can ServiceNow users be synchronized back to Okta when created locally in ServiceNow?

ServiceNow does not provide out-of-box bidirectional user synchronization to Okta, but this can be achieved using Integration Hub flows with the Okta spoke or custom RESTMessageV2 implementations. Configure Business Rules on the sys_user table to trigger outbound API calls when users are created or modified in ServiceNow. The integration requires careful conflict resolution logic to handle scenarios where users exist in both systems. Consider using Okta as the authoritative source for user identity to avoid synchronization conflicts and data inconsistencies.

How do I handle users who need access to multiple ServiceNow instances with different role requirements?

Create separate Okta applications for each ServiceNow instance with distinct SCIM configurations and group mappings tailored to each environment's role structure. Use Okta's application assignment rules and group policies to control which users can access specific ServiceNow instances based on organizational criteria. Configure different Identity Provider records in each ServiceNow instance to map Okta groups to environment-specific roles like 'prod_admin' versus 'dev_user'. This approach maintains security isolation while allowing centralized user management through Okta's identity governance features.

What happens to ServiceNow user data when the Okta integration is temporarily unavailable?

ServiceNow users provisioned through Okta retain their existing access and role assignments during Okta outages, as authentication and authorization data is cached locally in ServiceNow. However, new user provisioning, role updates, and SSO authentication will fail until connectivity is restored. Configure emergency access procedures using local ServiceNow accounts for critical administrators, and implement Integration Hub error handling to queue failed provisioning attempts for retry when Okta becomes available. Monitor integration health proactively to minimize the impact of service disruptions on user productivity.

Can I use Okta Universal Directory attributes for advanced ServiceNow user field mapping beyond basic profile information?

Yes, ServiceNow SCIM implementation supports custom attribute mapping from Okta Universal Directory through SCIM schema extensions and custom Transform Maps. Configure Okta to send additional user attributes in SCIM provisioning payloads, then create custom Transform Map scripts in ServiceNow to populate fields like department, manager, location, and cost center. Use the SCIM 2.0 enterprise schema extensions for standard organizational attributes, or implement custom schema extensions for organization-specific user metadata. Test attribute mappings thoroughly to ensure data type compatibility and field length limitations in ServiceNow user records.

How do I implement just-in-time role provisioning based on ServiceNow module access patterns?

Implement custom Business Rules and Client Scripts in ServiceNow to detect when users attempt to access modules they lack permissions for, then trigger Integration Hub flows to request temporary role elevation through Okta workflows. Configure Okta group policies with time-based expiration to automatically remove elevated permissions after defined periods. Use ServiceNow's Access Control debugging features to identify required roles for specific module access, and create approval workflows that notify managers before granting temporary elevated access. This approach requires careful security controls to prevent privilege escalation abuse while supporting legitimate just-in-time access needs.

What is the recommended approach for migrating existing ServiceNow users to Okta-managed authentication?

Plan a phased migration starting with pilot user groups to validate SSO and provisioning functionality before full deployment. Export existing ServiceNow user data and match users to Okta identities using email addresses as primary keys, handling conflicts through manual review processes. Configure Okta SCIM to update existing users rather than create new records, and use ServiceNow's Identity Provider testing features to validate authentication flows. Create communication plans for users explaining SSO changes and password policy updates, and maintain emergency local accounts for critical system administrators during the transition period.

How can I audit and report on Okta-driven access changes in ServiceNow for compliance purposes?

ServiceNow automatically logs SCIM provisioning activities in System Logs and maintains audit trails for role assignments in the User Role audit table (sys_user_has_role_audit). Create custom reports using ServiceNow Reporting or Performance Analytics to track user lifecycle events, role changes, and access patterns driven by Okta synchronization. Configure Event Rules to capture specific integration events and route them to compliance monitoring systems or SIEM platforms. Use ServiceNow's Data Export capabilities to generate periodic compliance reports showing user access changes with source attribution to Okta group modifications, supporting regulatory requirements like SOX and GDPR.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue