Questions Regarding OPA Requirement and OPS Standalone Operation

Hello @--.20920 (Customer)​ Thank you for posting on our Community page!

You are asking whether the Okta Provisioning Server (OPS) can operate independently from the Okta Provisioning Agent (OPA) and On-premises Connector (OPC) in two specific scenarios: (1) using OPS with OPC but without OPA, and (2) using OPS as a standalone SCIM server without OPC, and whether these configurations are technically possible and officially supported by Okta.

Can the Okta On-prem SCIM Server operate without the Okta Provisioning Agent in an environment using the On-premises Connector?

Technically possible: No.

Officially supported: No.

The traditional Okta OPP architecture relies on a secure polling mechanism to avoid requiring open inbound firewall ports. Okta places requests in a secure queue rather than pushing provisioning events directly from the cloud to on-premises servers.

The OPA establishes an outbound connection to Okta via port 443 to poll for queued System for Cross-domain Identity Management (SCIM) requests. Once OPA retrieves a request, it forwards the request locally over port 1443 to the OPS.

The OPS lacks a built-in polling mechanism. It functions as a local translator that receives the SCIM payload from OPA and translates it into the appropriate SQL or Java Database Connectivity (JDBC) commands for the target database. Without OPA to retrieve the messages from Okta, OPS remains idle and never receives provisioning data.

Configure the minimum officially supported architecture by implementing the following components.

1. Administrators configure Okta Cloud with the OPC for Generic Databases.
2. Administrators install OPA on an on-premises Windows or Linux server to handle outbound polling.
3. Administrators install OPS on the same server, or an adjacent server, as OPA to run locally.
4. The server hosting OPS accesses a target database via JDBC.

Independent operation of the Okta On-prem SCIM Server without the On-premises Connector or Okta Provisioning Agent is unsupported.

Technically possible: Yes, with custom network engineering.

Officially supported: No.

Because OPS exposes a standard SCIM 2.0-compliant REST API locally, administrators can technically place a reverse proxy in front of it, open an inbound firewall port to the internet, and connect a generic Okta cloud SCIM integration directly to the public endpoint.

However, Okta strictly does not support this configuration. Okta engineered OPS specifically as a lightweight, local listener designed to sit securely behind a firewall and receive requests exclusively from OPA. Exposing OPS directly to the public internet bypasses the Okta security design for on-premises infrastructure. To use a direct Okta-to-SCIM integration without OPA or OPC, administrators must host and secure a custom internet-facing SCIM server.

In the traditional architecture, OPS functions as a companion component that requires concurrent use with OPC and OPA. Okta does not design, license, or support OPS for independent use in a separate, standalone SCIM integration environment.

The unified Okta On-prem SCIM agent replaces the legacy split-agent architecture.

Okta released the unified Okta On-prem SCIM agent to replace both the OPA and the OPS for the On-Prem Connector for Generic Databases.

This single agent unifies the outbound polling mechanism and the SCIM-to-Database translation into a single, officially supported binary. Administrators seeking to reduce dependencies and avoid managing two separate agents must upgrade to the new Okta On-prem SCIM agent instead of attempting unsupported configurations.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.