This article outlines how to securely configure the Okta Spoke in ServiceNow following the principle of least privilege. It captures additional setup steps not documented in standard product guides and reflects a collaborative approach with ServiceNow product and support teams.
The Okta Spoke is a powerful integration that allows ServiceNow to do many neat things in Okta. There are almost 50 discrete Flow actions that your organization may find incredibly useful. However, our information security team, the business owner of Okta, rightfully called out actions that we didn't need for our integration use case. A great example was "Delete User." The specifics aren’t important, but what you need to know is how to pare back the integration to observe the principle of least privileged access. This will give your integration partner comfort that you know what you’re doing, that you build with security in mind.
From within Okta:
- Create a service account in Okta. Hopefully you are using Okta’s Life Cycle Management, and the service account will be provisioned as a ServiceNow user as well. Don’t mark the ServiceNow user “web-access only” … yet.
- Create a resource set. Assign the appropriate groups, users, & applications that may be managed by ServiceNow. Allow the service account permission to the resource set.
https://help.okta.com/en-us/content/topics/security/custom-admin-role/create-resource-set.htm
We maintain this moving forward as a standard change (pre-approved) to expand the resource set as needed. - Set up new app integration using OAuth credentials
https://www.servicenow.com/docs/bundle/yokohama-integrate-applications/page/administer/integrationhu...
Under the tab for Okta API Scopes
Only set the API scopes that are relevant to your business case.
You do not need all 9 listed in setup instructions.
( We are currently using only 2 in sub-prod and 3 in production instance )
- Assign Service Account to the new App integration
From within ServiceNow:
- Grant the new service account created via Life Cycle Management temporary elevated access to configure Workflow integration.
- Open a Chrome Incognito browser, so you’re Okta creds will not be cached. Impersonate the service account. (See above)
- Open the Workflow Studio and enter all the connection details, and when you hit the button “Configure and Get OAuth Token” please be sure to use the service account credentials in the Okta pop-up window.
Note: if you don’t use Life Cycle Management to populate your user table, you may need to assign the ServiceNow developer to the new Okta application integration, temporarily just to get the Authentication window to pop open. The important part is that the credentials used in the Okta pop-up window belong to the service account, not the human sys admins of either Okta/ServiceNow.
Congratulations, you should have an Access Token with the correct permissions!
The bad news is that the token will expire in an hour, and it won’t refresh without this next step.
- In an effort to be “efficient” the Okta Spoke has a template that hardcodes all nine(9) API scopes. It creates 9 entries on the OAuth Entity Profile Scopes table. oauth_entity_profile_scope.
* UX may be cleaner from oauth_entity_profile record. See screen cap below
If the records here do not match the API scopes listed in Okta, the token will not refresh.
A tenth record is created for "Offline Access." This is the only entry you must keep
Delete the other entries that were purposefully excluded from the API scope of the app integration in Okta.
Permissions clean-up and Validation
- In ServiceNow
- Mark service account “Web service access only”
- Remove any temporary elevated access required for configuring Spoke
- In Okta
- Remove all human sys admins from the Application integration assignment.
- Test your specific functionality
- Test your Token Refresh
Special thanks to @Edwin Kwan
CC: @Tyler Duke @Michael Mindel
