Hey folks, running into a bit of a wall with the Genesys Cloud OAuth flow for a multi-tenant BPO setup. We’ve got a Terraform module that provisions a new genesyscloud_oauth_client for each client account, but the issue is scope. By default, the client seems to have access to everything in the organization, which is a no-go for our security requirements. I need to restrict the client to only see resources in its specific division.
I’ve been digging through the /api/v2/oauth/clients documentation, but there’s no explicit divisionId field in the creation payload that limits the client’s visibility. The client itself is organization-wide. What I’m trying to do is use the division header in subsequent API calls to filter results, but the token generated by this client still returns data from other divisions if the user associated with the token has access there.
Here’s the Terraform snippet I’m using:
resource "genesyscloud_oauth_client" "client" {
name = "${var.client_name}-api-client"
description = "API client for ${var.client_name}"
client_type = "CONFIDENTIAL"
redirect_uris = ["https://myapp.com/callback"]
}
And here’s how I’m getting the token:
curl -X POST "https://api.mypurecloud.com/oauth/token" \
-H "Authorization: Basic ${base64(client_id:client_secret)}" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials"
The token comes back fine, 200 OK. But when I hit /api/v2/users with the X-Genesys-Organization-Id header set to the specific division, it still returns users from other divisions if the client’s service account has broader permissions. I’m trying to avoid having to manage division-level permissions for every single user manually.
Is there a way to scope the OAuth client itself to a division? Or do I need to use a different grant type, like authorization_code with a specific user context? I’ve tried setting the division_id in the client config, but the API just ignores it or throws a 400 Bad Request saying it’s not a valid field.
Any ideas on how to enforce this boundary at the token level rather than relying on application-side filtering?