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:

• User role assignments
• Group role assignments
• Client role assignments

For custom role assignments, follow these steps:

1. Create a custom role.
2. Create a resource set.
3. 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 the okta.users.groupMembership.manage, okta.groups.manage, and okta.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, or ORG_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 the okta.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.

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.

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

Supported resources

Directory service

Identity Provider service

Workflow service

Governance service

Note: Governance resources are currently only supported as part of the standard resource sets. You can't use these to create or update other resource sets. See IAM-based standard roles.

Identity and Access Management service

Shared Signals Framework service

Support service