Requirements and limitations

Workload authentication has the following requirements and limitations.

Authentication requirements

Identity source: The workload must be able to authenticate using JSON web tokens (JWTs).
Provider support: Authentication is limited to JWTs. Okta Privileged Access provides out-of-the-box support for verifying JWTs from specific federated providers, including Google Cloud Platform, GitLab, and CircleCI.
Required client tooling: You must use the Okta Privileged Access client CLI for non-interactive tasks and workload authentication types.
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.

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.
No specific 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.
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.

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.