For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
The Moveworks service interacts with your Okta instance to carry out one or more of the following depending on the level of access provided:
Identify employees (read-only)
Notify employees of account lockout events (read-only)
Notify employees of upcoming password expirations (read-only)
Fulfil employees’ software provisioning requests
Help employees reset passwords
Unlock locked accounts
Help employees reset their multi-factor authentication
Note
In a read only environment, Moveworks will not attempt to take an action directly for the user. In that case, the bot will provide instructions to the user, or direct the user to a preferred portal to execute the action of resetting a password or unlocking an account.
Not all Moveworks+Okta deployments handle all of the tasks mentioned above. In some deployments, password and account issues are handled through Moveworks’ direct interaction with Active Directory.
General Setup
Moveworks supports both Service Account based API Token Authentication and JWT based OAuth Authentication to interact with your Okta instance. Please refer to
Required Permissions
Depending on the capabilities that you want to enable for your employees using Moveworks, you can provide fine-grained permissions to the Service Account or the App Integration based on your preferred mode of authentication.
For organizations where Moveworks integrates with Okta for read-only capabilities, the API token must have the following permissions in Okta:
Read-only Admin
For organizations where Moveworks integrates with Okta to give employees access to software, the API token must have the following permissions in Okta:
Group Admin
Optional: You may choose to constrain the Group Admin Role to only allow the service account to operate on a specific subset of groups.
App Admin
Optional: You may opt to use a custom admin role with the okta.users.readpermission if your organization only uses group-based membership to provision access to software.
For organizations where Moveworks integrates with Okta to help employees with passwords, account unlock, and multi-factor reset, the API token must have the following permissions in Okta:
Help Desk Admin
Report Admin
For more information on what permissions are entailed in each role, please refer to Okta’s documentation.
Service Account Authentication
The service account in Okta allows the Moveworks service to read user profile information, account lockout events, and password expiration information, fulfil provisioning requests by adding users to groups in Okta.
Use this service account to create an API Token by following the instructions present in Okta’s documentation.
Configure in Moveworks Setup
Within Moveworks Setup, go to Manage Connectors > System Connectors, then click on ‘CREATE NEW’
Click on the ‘Okta’ Connector, then click on ‘NEXT: ADD CREDS’
Type out the name of the connection, select Common Base URL and enter the name of your instance.
4. Select the Authentication Type as API Key Auth
5. Enter the API Token you generated previously in the API Key field and save the Connector.
Your Okta Connector is now ready to be configured for the relevant skills using Moveworks Setup.
OAuth 2.0 with JWT-based Authentication
In order to utilize OAuth 2.0, please follow the below steps:
Create a Service App Integration in Okta
Create an OAuth 2.0 service app integration using the Okta Admin Console.
Sign in to your Okta organization as a user with administrative privileges.
In the Admin Console, go to Applications > Applications, and then click Create App Integration. The Create a new app integration page appears.
Select API Services as the Sign-in method, and then click Next.
Enter a name for your app integration and click Save.
Configure the Authentication for your App
Once the App is created, it will open the Application page.
Within the Client Credentials section, click on the Edit button.
In the Client authentication section, select Public key / Private key as our preferred method of authentication.
Once selected, the PUBLIC KEYS section would appear. Here, make sure that the Save keys in Okta is selected for Configuration.
Click on Add key to add a new public key for your application.
In the Add a public key page that opens up, click on Generate new key.
Once your public-private key pair is generated, click on the PEM button to view the certificate and then copy and save it in a safe storage as a .PEM file extension. This will be required later on to create the Connector in Moveworks Setup.
Click on Done once you have saved the Private key and then click on the Save button to save all of your configurations.
A pop-up will show which asks for confirmation if you want to change your authentication method. Click on Save again here to make all of the changes.
Head over to the General Settings section and click on the Edit button.
Deselect the Require Demonstrating Proof of Possession (DPoP) header in token requests checkbox and click on the Save button to save your configurations.
Grant allowed Scopes to the App
Now that you’ve created the service app and registered the public key with that service app, you need to define the allowed scopes. When a request is sent to the authorization server’s /token endpoint, it validates all requested scopes in the request against the service app’s grants collection. If the scope exists in the grants collection, the scope is granted.
From the service app page, select the Okta API Scopes tab.
Click Grant for each of the scopes that you want to add to the app’s grant collection.
Find the following API Scopes in the page and grant consent for them:
okta.apps.read
okta.apps.manage
okta.factors.read
okta.factors.manage
okta.groups.read
okta.groups.manage
okta.users.read
okta.users.manage
okta.orgs.read
okta.logs.read
The changes should reflect immediately upon granting consent.
