Okta API Returns a 403 Forbidden Error When Adding a User to a Group

Okta returns a 403 Forbidden error when an administrator attempts to add a user to a group via the Okta API. This occurs because the application or token lacks the necessary permissions or resource set access to modify the target user or group. Update the custom admin role and resource set configured on the service application to resolve the issue.

When making a request to the <OKTA_DOMAIN>/api/v1/groups/<group_id>/users/<user_id> endpoint, Okta generates the following error and does not record the event in the System Log:

Add-to-group [403]: {"errorCode":"E0000006","errorSummary":"You do not have permission to perform the requested action","errorLink":"E0000006","errorId":"xxxxx","errorCauses":[]}

Okta blocks 403 Forbidden errors at the API authorization layer before the request modifies the resource, preventing Okta from registering an auditable event in the System Log.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta API
• Custom Admin Roles

The service application uses a custom admin role that restricts access to specific resources, and the resource set omits the target group or user. Other causes include the target user possessing higher administrative privileges than the service application, an external directory sourcing the group, or the user existing in a suspended or deprovisioned state.

How is the resource set updated for the custom admin role?

Review the service application's custom admin role and add the target group to the resource set.

1. Navigate to the Okta Admin Console.
2. Go to Security and select Administrators.
3. Select the Roles tab and locate the service application's custom admin role.
4. Select the Resources tab and verify that the target group and target user fall within the management boundary.
5. Edit the resource set to include the target group.

What other configurations cause a 403 Forbidden error?

Verify the group source, user state, and administrator hierarchy to ensure no other configurations block the API request.

• Group Source and Type: Make a GET request to <OKTA_DOMAIN>/api/v1/groups/<group_id>. If the group type is BUILT_IN or APP_GROUP (sourced from Active Directory, Lightweight Directory Access Protocol (LDAP), Workday, or Google Workspace), the administrator must add the user in the downstream application. If the group uses Group Rules, Okta prevents explicit API additions.
• Administrator Hierarchy: Okta blocks a lower-privileged service application from modifying a higher-privileged user. Navigate to the user profile in the Okta Admin Console, select the Admin Roles tab, and verify the user does not hold a higher role (such as Super Administrator) than the service application.
• User State: Make a GET request to <OKTA_DOMAIN>/api/v1/users/<user_id>. If the user is DEPROVISIONED or SUSPENDED, Okta generates a 403 error depending on the administrator scope.
• OAuth 2.0 Scopes: Ensure the service application possesses the okta.groups.manage scope.