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, AWS IAM-based for workloads that have Amazon Web Services (AWS) credentials, or API key-based for on-premises 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.

AWS IAM authentication workflow

AWS IAM connections use the same split-duty process as JWT connections. The differences are in how you create the connection and how the workload authenticates.

Phase	Role	Action
Phase 1: Connect	DevOps admin	Creates the AWS IAM workload connection in Draft status by entering the AWS account ID and, optionally, the AWS identity that the workload must use. See Create an AWS IAM workload connection.
Phase 2: Governance	Security admin	Reviews and promotes the connection from Draft to Active. See Manage a workload connection.
Phase 3: Logic	Security admin	Creates a workload role that selects the AWS IAM connection and, optionally, narrows access by AWS identity. 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	Adds the `sft wl auth` command with the `--aws` flag to the workload, referencing the active workload connection name. The workload authenticates with the AWS credentials in its environment. See CLI command for workload authentication.

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.