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.

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

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.