Hi,
We’re building a third-party application that integrates with the Foundry Admin API v2 using OAuth 2.0 (Authorization Code flow). Most endpoints work correctly with our OAuth access token, but we consistently receive a 403 PERMISSION_DENIED response when calling the Organization Role Assignments APIs.
Affected Endpoints
The issue appears to be limited to the following endpoints:
* GET /api/v2/admin/organizations/{organizationRid}/roleAssignments
* POST /api/v2/admin/organizations/{organizationRid}/roleAssignments/add
* POST /api/v2/admin/organizations/{organizationRid}/roleAssignments/remove
Behavior Observed
Using an OAuth application access token:
* All Organization Role Assignments endpoints return 403 PERMISSION_DENIED.
Using a PAT (Personal Access Token) generated by the same user:
* The same requests succeed.
* The user has the expected permissions to view and manage organization role assignments.
All other endpoints we use work correctly with the OAuth token, including:
* Users
* Groups
* Group membership management
* Available roles
* Organizations
* Filesystem spaces, folders, and resources
* Resource role assignments
This suggests the issue is specific to authorization of the Organization Role Assignments APIs when using an OAuth application token.
Error Response
{
“errorCode”: “PERMISSION_DENIED”,
“errorName”: “ListOrganizationRoleAssignmentsPermissionDenied”,
“errorInstanceId”: “bfc731c6-722f-456a-942d-dca06d220f14”,
“errorDescription”: “The provided token does not have permission to list assigned roles for this organization.”,
“parameters”: {
“organizationRid”: “ri.multipass..organization.{{organization_id}}”
}
}
Troubleshooting Performed
We have:
* Granted the OAuth application the following scopes:
* api:admin-read
* api:admin-write
* api:filesystem-read
* api:filesystem-write
* api:aip-agents-write
* offline_access
* Tested multiple scope combinations, with no change in behavior.
* Reproduced the issue in Postman using the OAuth access token.
* Verified that the same requests succeed when using a PAT from the same user account.
Based on these tests, the issue appears to be related to how the OAuth application’s token is authorized rather than to our client implementation.
Questions
- What permissions are required for an OAuth application to list and modify Organization Role Assignments?
- Are there any additional scopes, application grants, enrollment-level settings, or organization-specific permissions required for these endpoints beyond the documented admin scopes?
- Is access to Organization Role Assignments intentionally restricted for OAuth applications, even when the corresponding user can perform the action via a PAT?
- What is the recommended configuration for a third-party OAuth application that needs to read and manage organization role assignments across organizations within an enrollment?
Any guidance would be greatly appreciated. Please let us know if additional information, request IDs, or configuration details would be helpful for troubleshooting.
Thank you.