403 insufficient_scope when updating user risk through Identity Threat Protection API

Hello @EricK.85454 (Customer)​ Thank you for posting on our Community page!

You are receiving a 403 Forbidden error with an insufficient_scope

error when your service integration attempts to call the Okta Identity Threat Protection User Risk API to update user risk levels, and you need confirmation of the complete OAuth scope, role, and feature configuration required for this integration to succeed.

The error indicates that your access token does not include the okta.userRisk.manage

OAuth scope. Here is the complete configuration checklist:

Solution:

1. Confirm the okta.userRisk.manage scope is granted to your service app. Yes, the okta.userRisk.manage OAuth scope must be explicitly granted to your OIDC or API service application. This scope is required in the token request and must be present in the access token returned by the authorization server. Verify in your Okta Admin Console that the scope is listed under the app's API Scopes or OAuth 2.0 Scopes configuration. If you are using a custom authorization server, ensure the scope is also defined and granted there.
2. Verify the service app has the required admin role or permission. In addition to the OAuth scope, the service app's associated service account or user must have an admin role that includes the User Risk management permission. This is typically granted through a role such as User Risk Administrator or a custom role with the Manage User Risk permission. Assign the appropriate role to the service app's user account in the Admin Console under Users or Service Accounts (depending on your Okta version).
3. Confirm Identity Threat Protection is enabled and licensed. Identity Threat Protection must be enabled as a feature in your Okta organization, and your organization must have the appropriate license or entitlement. Verify in the Admin Console under Security → Identity Threat Protection that the feature is active. If it is not visible or enabled, contact your Okta account team to confirm your organization has the ITP entitlement.
4. Mint a new access token after updating scopes and roles. After you grant the okta.userRisk.manage scope to the app and assign the required admin role, the changes take effect immediately. However, any existing access tokens will not be updated retroactively. You must request a new access token from the authorization endpoint using the client credentials flow (or the appropriate OAuth flow for your integration). The new token will include the okta.userRisk.manage scope and will be valid for calls to the User Risk API.

Additional verification steps:

• Confirm that your token request is explicitly requesting the okta.userRisk.manage scope in the scope parameter of the authorization request.
• If you are using a custom authorization server, verify that the scope is included in the server's scope list and that the app is granted access to it.
• Test the new token by making a simple GET request to /api/v1/users/{userId}/risk
• first to confirm the scope is present before attempting an upsert operation.
• If the 403 error persists after minting a new token, verify the Okta request ID in your logs and contact Okta Support with that ID to confirm there are no organization-level restrictions or feature flags affecting the User Risk API.

We hope this resolves the issue.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Thank you for the response.

We have already completed all the listed steps: granted okta.userRisk.manage, assigned the required role, confirmed ITP is enabled and licensed, requested a new token, and tested again. However, we still receive the same 403 insufficient_scope error.

Other workflows and connectors, including Okta and Okta Identity Governance, are working correctly. The issue occurs only with the Okta Identity Threat Protection connector.

Could you please advise what else we should check? Does this API require a token from the Org Authorization Server instead of a custom authorization server?

Please advise,