Roles in Okta
Overview
Okta provides roles to define the scope of privileges in your org so that admins have the appropriate level of access to complete their tasks. By default, each org contains a set of standard admin roles with predefined permissions to access predefined resources. You can extend the list of roles in your org and create custom admin roles with specific permissions to access specific resources.
When you assign an admin role to a principal, you grant them a specific set of access privileges. Principals can be users, groups of users, or client apps. When a role is assigned to a group, all members of the group automatically have the privileges that are granted by the role.
For standard role assignments, see the following principal-specific assignment APIs:
For custom role assignments, follow these steps:
- Create a custom role .
- Create a resource set .
- Create a resource set binding with your custom role and principal members.
Notes
- When you create a custom service app to access Okta APIs, you must assign an admin role to your app since admin roles aren't automatically assigned to apps. See Assign admin roles to the OAuth 2.0 service app .
- A principal with a custom admin role can't add or remove the super admin (
SUPER_ADMIN
) standard role to or from another principal. This custom role operation isn't permitted regardless of the permissions for the custom role. For example, a service app with an assigned custom role can't make an API request to assign the super admin role to a group, even if the custom role has theokta.users.groupMembership.manage
,okta.groups.manage
, andokta.users.manage
permissions.
IAM access to API resources
Okta recommends that you grant your principal (user, group, or client) least privilege access to API resources. To grant least privilege access to API resources, assign the principal a standard or custom admin role with minimal permissions.
The suggested standard admin roles and custom admin permissions are documented for some Okta API resource operations. For some use cases that involve cross-resources in the operation, you may need two or more admin roles or permissions for a successful request.
For example, if you want to request a governance operation on an app resource, you may require both the ACCESS_CERTIFICATIONS_ADMIN
and the APP_ADMIN
standard roles assigned to you.
Another example is shown in the Retrieve a user schema operation:
Admin roles:
API_ACCESS_MANAGEMENT_ADMIN
APP_ADMIN
ORG_ADMIN
Permissions:
okta.apps.manage
In this example, you need to assign the
API_ACCESS_MANAGEMENT_ADMIN
,APP_ADMIN
, orORG_ADMIN
standard admin roles to your principal for them to access the operation for common use cases. Or if your principal is assigned a custom admin role, that role must include theokta.apps.manage
permission for them to access the Retrieve a user schema operation.
Standard roles
The following standard roles are available in all Okta orgs. Standard roles have predefined permissions and access to predetermined resources. You can optionally narrow the list of predetermined resources by specifying resource targets when you assign the standard role to a principal.
See Standard administrator roles and permissions for a list of permissions included in each standard admin role.
Note: Use the enumerated values in the Role column for the
type
parameter when you assign standard admin roles.
Role | Label | Optional targets |
---|---|---|
API_ACCESS_MANAGEMENT_ADMIN |
API Access Management Administrator | |
APP_ADMIN |
Application Administrator | Apps |
GROUP_MEMBERSHIP_ADMIN |
Group Membership Administrator | Groups |
HELP_DESK_ADMIN |
Help Desk Administrator | Groups |
MOBILE_ADMIN |
Mobile Administrator | |
ORG_ADMIN |
Organization Administrator | |
READ_ONLY_ADMIN |
Read-only Administrator | |
REPORT_ADMIN |
Report Administrator | |
SUPER_ADMIN |
Super Administrator | |
USER_ADMIN |
Group Administrator | Groups |
IAM-based standard roles
IAM-based standard roles have the custom roles format, where preset permissions and resource sets are bound to the IAM-based standard role. However, these IAM-based standard roles are still immutable. You can't update the role, the permissions, or the resource set.
Role | Label | Resource set | Permissions |
---|---|---|---|
ACCESS_CERTIFICATIONS_ADMIN |
Access Certifications Administrator | ACCESS_CERTIFICATIONS_IAM_POLICY |
okta.governance.accessCertifications.manage , okta.governance.collections.read , okta.apps.read , okta.users.read , and okta.groups.read |
ACCESS_REQUESTS_ADMIN |
Access Requests Administrator | ACCESS_REQUESTS_IAM_POLICY |
okta.governance.accessRequests.manage , okta.apps.assignment.manage , okta.governance.collections.read , okta.groups.appAssignment.manage , okta.apps.manageFirstPartyApps , okta.apps.manage , and okta.users.appAssignment.manage |
WORKFLOWS_ADMIN |
Workflows Administrator | WORKFLOWS_IAM_POLICY |
okta.workflows.flows.invoke , okta.workflows.flows.manage , okta.workflows.flows.folders.manage , okta.workflows.tables.manage , okta.workflows.connections.manage , and okta.workflows.connectors.manage |
You can assign a Workflows IAM-based standard role for users or groups to manage the Workflows product. See Workflows Administrator. Within the Workflows console, users with the Workflows admin or the super admin roles can also assign granular role-based access to manage workflows resources. See Resource-based Access Roles.
Permissions
For custom roles, permissions allow the principal to perform tasks and access resources. See Permissions for more information.
Resources
Okta resources are identified with either an Okta Resource Name (ORN) or an Okta API REST URL.
Note: Not all Okta resources have a corresponding Okta API.
Okta Resource Name (ORN)
The Okta Resource Name (ORN) uniquely identifies an Okta resource and has the following formats:
-
orn:{partition}:{service}:{yourOrgId}:{objectType}:{objectId}:contained_resources
-
orn:{partition}:{service}:{yourOrgId}:{objectType}:{appName}:{objectId}
-
orn:{partition}:{service}:{yourOrgId}:contained_resources
ORN variable | Description |
---|---|
{partition} |
The Okta environment partition specific to your org (oktapreview for Preview environments and okta for Production environments) |
{service} |
The service that the resource belongs to |
{yourOrgId} |
The identifier for the tenant that's using the service. This is typically your org ID. |
{objectType} |
The resource object that belongs to the service category |
{objectId} |
The specific object identifier for objectType . For example, if you want to define a specific group for your resource, use orn:{partition}:directory:{yourOrgId}:groups:{groupId} . |
{appName} |
The key name that describes the app definition. For example, if you want to define all apps with a specific app definition for your resource, use orn:{partition}:idp:{yourOrgId}:apps:{appName} . |
contained_resource |
An optional literal that targets all resources within the container resource (only for supported resources). For example, orn:{partition}:directory:{yourOrgId}:groups:{groupId}:contained_resources targets all users within a specific group. |
{realmId} |
The identifier of the realm. For example, orn:{partition}:directory:{yourOrgId}:realms:{realmId}:users targets all users within a specific realm. |
Supported resources
Directory service
Resource | ORN | Okta API REST URL |
---|---|---|
All users | orn:{partition}:directory:{yourOrgId}:users |
https://{yourOktaDomain}/api/v1/users |
All groups | orn:{partition}:directory:{yourOrgId}:groups |
https://{yourOktaDomain}/api/v1/groups |
A specific group | orn:{partition}:directory:{yourOrgId}:groups:{groupId} |
https://{yourOktaDomain}/api/v1/groups/{groupId} |
All users within a specific group | orn:{partition}:directory:{yourOrgId}:groups:{groupId}:contained_resources |
https://{yourOktaDomain}/api/v1/groups/{groupId}/users |
All devices | orn:{partition}:directory:{yourOrgId}:devices |
https://{yourOktaDomain}/api/v1/devices |
All realms | orn:{partition}:directory:{yourOrgId}:realms |
https://{yourOktaDomain}/api/v1/realms |
A specific realm | orn:{partition}:directory:{yourOrgId}:realms:{realmId} |
https://{yourOktaDomain}/api/v1/realms/{realmId} |
All users within a specific realm | orn:{partition}:directory:{yourOrgId}:realms:{realmId}:users |
Identity Provider service
Resource | ORN | Okta API REST URL |
---|---|---|
All apps | orn:{partition}:idp:{yourOrgId}:apps |
https://{yourOktaDomain}/api/v1/apps |
All Identity Providers |
orn:{partition}:idp:{yourOrgId}:identity_provider |
https://{yourOktaDomain}/api/v1/idps |
All apps of a specific type | orn:{partition}:idp:{yourOrgId}:apps:{appType} |
https://{yourOktaDomain}/api/v1/apps/?filter=name+eq+%22{targetAppType}%22 |
A specific app | orn:{partition}:idp:{yourOrgId}:apps:{appType}:{appId} |
https://{yourOktaDomain}/api/v1/apps/{appId} |
All authorization servers | orn:{partition}:idp:{yourOrgId}:authorization_servers |
https://{yourOktaDomain}/api/v1/authorizationServers |
A specific authorization server | orn:{partition}:idp:{yourOrgId}:authorization_servers:{authorizationServerId} |
https://{yourOktaDomain}/api/v1/authorizationServers/{authorizationServerId} |
All customizations | orn:{partition}:idp:{yourOrgId}:customizations |
|
Entity risk policy | orn:{partition}:idp:{yourOrgId}:policies:{policyType} |
https://{yourOktaDomain}/api/v1/policies?type={policyType} where {policyType} = ENTITY_RISK |
Session protection policy | orn:{partition}:idp:{yourOrgId}:policies:{policyType} |
https://{yourOktaDomain}/api/v1/policies?type={policyType} where {policyType} = POST_AUTH_SESSION |
Workflow service
Resource | ORN | Okta API REST URL |
---|---|---|
All delegated flows | orn:{partition}:workflow:{yourOrgId}:flows |
|
A specific delegated flow | orn:{partition}:workflow:{yourOrgId}:flows:{flowId} |
Governance service
Resource | ORN | Okta API REST URL |
---|---|---|
All access certifications | orn:{partition}:governance:{orgId}:certifications |
|
All access requests | orn:{partition}:governance:{orgId}:requests |
Identity and Access Management service
Resource | ORN | Okta API REST URL |
---|---|---|
All Identity and Access Management resources | orn:{partition}:iam:{orgId}:contained_resources |
Shared Signals Framework service
Resource | ORN | Okta API REST URL |
---|---|---|
All SSF Receivers |
orn:{partition}:ssf:{yourOrgId}:security_events_providers |
https://{yourOktaDomain}/api/v1/security-events-providers |
Support service
Resource | ORN | Okta API REST URL |
---|---|---|
All Okta Support cases opened by the admin | orn:{partition}:support:{orgId}:cases |