Get started

Configure Okta Privileged Access to authenticate automated workloads so they can securely access privileged resources. Choose the authentication method that best fits your workload environment: JWT-based for cloud-native workloads with federated identity, or API key-based for on-premise and non-cloud environments.

Before getting started, review requirements and limitations to understand authentication prerequisites and constraints for your environment.

JWT authentication workflow

For JWT connections, the process requires collaboration between two admin roles:

DevOps admin: Creates and tests the machine's identity configuration and is familiar with the source system.
Security admin: Governs the access, approves the identity configuration for live use, and defines authorization policies.

For API key connections, only security admins perform all setup tasks, including connection creation, key generation, rotation, and revocation.

Phase	Role	Action
Phase 1: Connect	DevOps admin	Creates the workload connection in Draft status. In Draft mode, the CLI returns a successful validation message, but it doesn't issue a usable token. This allows you to verify your claim logic without granting access. See Configure workload connection. Tests the specific non-interactive command (`sft workload authenticate`) that the automation script uses. This verifies the CLI syntax and confirms that the workload's JWT passes validation against the draft connection. See CLI command for workload authentication. Note: If you run `sft workload authenticate` while in Draft state, the system requires approximately 5 minutes to refresh the workload connection details after switching to Active before issuing a tamper-proof Okta Privileged Access token.
Phase 2: Governance	Security admin	Reviews and promotes the connection from Draft to Active. See Manage a workload connection. Upon activation, the DevOps admin loses write access to the workload connection.
Phase 3: Logic	Security admin	Creates a workload role, defining the attribute-based conditions that determine who qualifies for the role. See Configure workload roles. Creates or updates the policy, selecting the new workload role as the principal. See Create or update a security policy.
Phase 4: Deploy	DevOps admin	Injects the `sft wl auth` into the workload's CI/CD pipeline. The automated workload runs the enhanced Okta Privileged Access client command, referencing the active workload connection name. Access events are logged to the Okta System Log.

API key authentication workflow

For API key connections, only security admins perform all setup tasks. The workflow is simpler than JWT because there's no split-duty review phase—the connection is created directly in active status and is immediately ready for key generation.

Phase	Role	Action
Phase 1: Connect	Security admin	Creates the API key workload connection in Active status. Unlike JWT connections, there's no draft phase. See Configure workload connection.
Phase 2: Generate	Security admin	Optionally configures API key claims (key-value pairs) that are included in workload tokens and used for role mapping. Generates the first API key for the workload. The raw key is revealed only once and you must copy it immediately. See Manage API keys. Delivers the API key to the DevOps engineer through a secure out-of-band channel.
Phase 3: Logic	Security admin	Creates a workload role, defining the attribute-based conditions that determine who qualifies for the role. See Configure workload roles. Creates or updates the policy, selecting the new workload role as the principal. See Create or update a security policy.
Phase 4: Deploy	DevOps admin	Injects the API key into the workload's environment (as an environment variable, configuration file, or secrets manager). Injects the `sft wl auth` command into the workload's CI/CD pipeline, referencing the active workload connection name. The workload uses the API key to authenticate. See CLI command for workload authentication. Access events are logged to the Okta System Log.