Okta Privileged Access – A Technical Introduction

The new Okta Privileged Access product was featured in the recent Oktane23 conference. The product became Generally Available on Dec 1 2023.

This article is a brief technical overview of Okta Privileged Access (OPA) looking at the components, functions and managed resource types of the product. It is written to provide a backdrop for other material looking at the capabilities of the product and to help architects understand where the pieces fit in the Okta landscape.

This article was originally written against the Limited Early Access release, but has been updated in Jun 2025.

Components of Okta Privileged Access

The following figure provides an overview of the OPA components.

The product comprises a set of (optional) infrastructure components and multiple cloud tenants. Let’s start at the bottom and work our way up the figure.

To support infrastructure privileged access (server and, soon, Kubernetes clusters) there are some installable components that are used – a Client that resides on the users workstation, an Agent that resides on the servers, and optionally a Gateway for network proxying. If you are familiar with Okta Advanced Server Access, these components are the same (more details can be found here). Note that Bastions are no longer used. There is an OPA Technical Guide for the Infrastructure Components available on the OPA Product Hub.

The next layer in the figure is the Okta Privileged Access tenant, called a “Team”. This is the cloud service for managing privileged access. It has it’s own datastore and also a Vault for storing credentials.

The next layer in the figure is the Okta platform, the Okta Workforce Identity (OWI). The Okta Privileged Access app (team) is represented as an application in Okta like any other SaaS application – it has SSO & provisioning, assigned users, push groups, authentication policies, and is in the OIN catalog. OPA will also leverage Universal Directory indirectly – through users and groups associated with the application. It will also leverage the System Log (more on this in the next section).

Sitting above WIC in the diagram are two components – Okta Access Requests and Okta Workflows. Okta Access Request is included in the OPA product in a limited form for a specific use case (see below), and extends access requests to other platforms like Slack/Teams and email. Okta Workflows is not part of the OPA product but may be useful for bespoke automation tasks (see some examples here). There is a Workflows connector for Okta Privileged Access.

All of these cloud components are sitting behind the Okta Dashboard.

Now lets dive into the functions provided by these components.

Functions of Okta Privileged Access

The following figure provides an overview of the OPA functions in the context of the components.

Again, let’s start at the bottom and work our way up the diagram looking at the functions (green boxes).

At the infrastructure layer the Gateway, in addition to providing the network proxying capability, can perform Session Recording of the SSH/RDP sessions flowing through it.

The Okta Privileged Access Team implements the PAM administration. This includes managing:

• PAM Users, Groups and Admin Roles – other then some baked-in local groups, all users and groups are pushed from Okta. The admin roles can be assigned to groups.
• Policy, Rules and Controls/Conditions – policies define who can access resources and rules within policies define how which includes any controls or conditions (MFA, Access Request, Session Recording)
• Resources, Connections and Mapping – resources are managed separately from policies. There are containers (resource groups) that can be assigned to administrators (delegated admin model) and projects with like resources grouped together. For some resource types, there are also connections to be managed and account mapping rules.

More information on the data objects and their administration can be found in https://iamse.blog/2023/10/18/okta-privileged-access-a-look-at-the-data-model/.

There is an API available for OPA.

Finally, the Vault enables the storage and control of access to Secrets, Managed Accounts and other resources.

The Okta Workforce Identity platform also provides functionality leveraged by OPA in addition to hosting the OPA application. OPA is writing Privileged Events into the System Log and can be subject to custom reporting. It is pushing users and groups to OPA application. The Okta integrations for AD (via the Directory Integration and AD Agent) and SaaS apps (via OIN apps) used for those resource types.

There are two main integrations between Okta and OPA:

1. OPA is an application in Okta like any other. It is leveraging OIDC for SSO and SCIM for LCM.
2. To support more recent resource types (Okta/SaaS Service Accounts, AD Accounts) a synchronisation mechanism has been built between the apps. This is used for discovery/import and password synchronisation (on rotation).

One of the policy controls implemented in OPA is the ability to run an access request when trying to access a resource. OPA includes a limited version of the Okta Access Requests component to implement Privileged Access Requests. OPA will call into Access Requests to raise a request which would then be reviewed/approved (say by a manager or service owner) and returns the result for OPA to allow or deny access to the resource. Whilst not part of the OPA product, Okta Access Requests (with an Okta Identity Governance license) could also be used to manage the groups memberships driving PAM roles and PAM policy assignment in OPA.

Okta Privileged Access Resource Types

When OPA was first released it only supported local servers and generic secrets. The following figure shows the complete list of resource types supported.

The current list is:

• Linux Servers – connect via SSH using JIT individual accounts or shared accounts
• Windows Servers – connect via RDP using JIT individual accounts or shared accounts
• Active Directory (AD) accounts – discover/manage AD accounts and allow them to be revealed and used
• Secrets – any credential stored in the vault and can be revealed and used
• SaaS Service Accounts – account credentials stored in the vault and can be revealed and used. If the OIN integration is available, OPA can manage the passwords for those accounts
• Okta Service Accounts – where accounts in Okta are shared amongst users, those accounts can be stored in the vault with password rotation, and allow reveal and use.

There are other PAM use cases that can be supported in the wider Okta Workforce platform, including:

• SaaS federated accounts where entitlement can be assigned dynamically and controlled through governance functions like access requests / certification
• Active Directory group membership managed in Okta, where those groups provide privileged access to domain-joined resources and can be controlled through governance functions like access requests / certification

This is a brief high-level view. Okta Privileged Access continues to mature and extend it’s scope.