Requirements and limitations

Workload authentication has the following requirements and limitations.

Authentication requirements

You can authenticate workloads using one of two methods: JWT-based authentication or API key-based authentication.

JWT authentication requirements

• Identity source: The workload must be able to authenticate using JSON web tokens (JWTs).

• Provider support: Okta Privileged Access provides out-of-the-box support for verifying JWTs from specific federated providers, including Google Cloud Platform, GitLab, and CircleCI.

• Non-federated identity: Non-cloud-hosted machines (without a trust provider like a cloud platform) need a customer-defined bootstrap mechanism to securely provide the required JWT proof. This mechanism solves the zero secret problem for these environments.

API key authentication requirements

• Security admin provisioning: Only security admins can create and manage API key connections and generate API keys.

• One-time reveal: API keys are revealed once at creation and must be copied immediately. You can't retrieve the key later.

• Out-of-band delivery: The security admin delivers the API key to the DevOps engineer through a secure channel outside of the Okta platform.

• Ideal for non-cloud workloads: API key connections are recommended for on-premise or non-cloud workloads that don't have access to a federated identity provider.

General requirements

• Required client tooling: You must use the Okta Privileged Access client CLI for non-interactive tasks and workload authentication.

Policy and access limitations

• No token refresh: The Okta Privileged Access token isn't refreshable. If the access token expires, the workload must fully re-authenticate by submitting a new JWT (for JWT connections) or API key (for API key connections).

• No specific token revocation: You can't revoke an individual access token. Setting a workload connection to inactive prevents new tokens from being issued. If the connection is activated again, the previously issued tokens will still work. For API keys, you can revoke individual API keys to prevent that key from being used to create new tokens.

• Policy design: Customers must design Okta Privileged Access policies using workload roles.

• User access failure: When a policy identifies both valid and invalid User Access Methods (UAMs), it returns only the valid option. If a workload receives multiple valid UAMs, the policy provides all possible options for the workload to select. Okta recommends defining workload roles clearly to avoid policy ambiguity.

  Note:

  An invalid UAM occurs when a security policy grants a workload access to a resource but includes interactive constraints, such as MFA, Access Requests, or project-level resource checkouts. Because workloads are autonomous and can't perform these human-required actions, any request triggering these requirements are automatically canceled.

• Workload identity visibility: You can't list or fetch workload identities directly through the public API; users can only see them through audit events.

API key limitations

• No self-rotation: Workloads can't rotate their own API keys. Only security admins can initiate key rotation.

• Cache delay on revocation: When an API key is revoked, it may take up to five minutes for the token issuer's cache to expire, during which existing cached tokens may still be accepted.

• No vault storage (GA release): API keys aren't stored in a secrets vault. Security admins must deliver keys out-of-band to workload teams. Vault storage and automatic key delivery are planned for future releases.

• No bulk operations (GA release): Bulk creation or rotation of API keys isn't available in the GA release. Each key must be created individually. Bulk operations are planned for future releases.