On-premises provisioning

Like cloud-based provisioning, on-premises provisioning uses the SCIM protocol to synchronize user account information between your user store and the apps that your users work with every day.

On-premises provisioning only supports the SCIM 1.1 specification.


The on-premises provisioning architecture consists of the following components: Okta, the Okta Provisioning Agent, a SCIM server or custom connectors, and your on-premises applications. As shown in this illustration, all components except Okta are located inside your firewall:


Okta only supports on-premises provisioning when Okta Professional Services does the implementation. For more information on how to implement Okta-supported on-premises provisioning, contact Okta Professional Services.

To implement Okta on-premises provisioning, you need the following:

  • The Okta Provisioning Agent installed on a Windows or Linux server.
  • A SCIM server to process the provisioning requests sent by the Okta Provisioning Agent. The SCIM server can be the connector you build using the Okta Provisioning Connector SDK or your own program than can process SCIM-based REST calls.
    • The Okta Provisioning Connector SDK package contains an example connector that you can use to test on-premises provisioning and to help you build your own connectors. Don't attempt to use the example connector without modifying it for your deployment.
  • The Transport Layer Security (TLS) v1.2 protocol for Linux and Windows.
  • For high availability on-premises provisioning, you must install an additional Okta Provisioning Agent and SCIM connector on another server. Start the Okta Provisioning Agent, configure your SCIM connector, and enable provisioning on your backup server. If your primary server is unavailable, the Okta Provisioning Agent and the processes run by your SCIM connector continue to operate.

User workflow

When a new user is provisioned from Okta to an on-premises application (for example, a MySQL database) using a SCIM server, this is the typical workflow:

  • An Okta admin creates an instance of an app integration in Okta to represent your MySQL on-premises application.
  • The admin provisions a new user by assigning an Okta user to the MySQL app integration in Okta. Okta creates a provisioning event (create new user). Okta provisioning fails when an application user custom schema contains only array attributes.
  • The Okta Provisioning Agent polls Okta and finds the provisioning event. The Okta Provisioning Agent translates the provisioning event to a SCIM request, making an HTTP POST request to the /Users endpoint of your SCIM server.
  • The SCIM server receives the POST request made to /Users with a JSON-formatted SCIM representation of the user. The server attempts to create that user in the on-premises app.
  • The SCIM server responds to the Okta Provisioning Agent with the SCIM response message as mandated by SCIM protocol.

For enterprises that onboard users using a Human Resource Management System (HRMS) like Workday, Okta provisions users to and deprovisions users from on-premises apps by using Active Directory (AD) as a meeting point. You can configure Okta to manage accounts in your AD instance, and Okta creates and updates users in AD based on the user accounts in Workday. Any on-premises apps that use AD as their user store can then use this information.

Related topics

Typical workflow for deploying on-premises provisioning

Provision on-premises apps

SCIM protocol specifications

Okta and SCIM 2.0