Hey, I have a customer with SSO configured through our Descope integration, using Azure AD (Entra ID) as their IdP with SCIM provisioning enabled. When Azure attempts to validate SCIM authorization, it's hitting:

GET <https://api.descope.com/scim/v2/Users?filter=userName+eq+>"<REDACTED_USER_ID>"

And receiving the following error response:

json
{
  "errorCode": "E111005",
  "errorDescription": "Management key does not match project",
  "errorMessage": "Invalid permission in request, access key must be associated with the correct permission for this action"
}

HTTP Status: 401 Unauthorized Our questions: 1. What is the correct SCIM base URL format we should be providing to customers for Azure AD provisioning — should it include the Descope Project ID as a path suffix? 2. What exact permissions does the management key need to have for SCIM provisioning to work? 3. Is SCIM provisioning enabled per-tenant or at the project level, and what does that configuration look like on your end? 4. Is there a way on the Descope console to verify whether a given SCIM token is valid and associated with the correct project, without having to regenerate it? Thanks

Hi, I'm Descope's AI assistant. I've put together an initial response below based on your question. --- ### SCIM Base URL The correct SCIM base URL to enter in Azure AD is:

<https://api.descope.com/scim/v2>

All SCIM endpoints follow the pattern

/scim/v2/...

under that base. ### Token & Key Requirements There are two distinct SCIM scenarios — make sure you're using the right one: • Tenant SCIM provisioning (most common): Use an Access Key scoped to the specific tenant with the

Tenant Admin

role. The Authorization header must be formatted as:

Authorization: Bearer <ProjectId>:<AccessKey>

• Company/Console (Descoper-level) SCIM: Use a Management Key generated from the Management Keys page with the "Descoper level access (SCIM)" role assigned. This is only for provisioning Descope console users, not end-user tenants. A common cause of 401 errors is using a management key where an access key is required (or vice versa), or omitting the

ProjectId:

prefix in the Bearer token. ### SCIM Provisioning Scope SCIM provisioning is configured per tenant and is tied to each SSO configuration, allowing one tenant to support multiple IdPs, each with its own SCIM integration. For more details, refer to the Descope Documentation. ### Verifying SCIM Token Validity In the Descope console, SCIM tokens are managed per-tenant under the SCIM Provisioning area. Navigate to the Tenants page → Authentication Methods → SSO → SCIM Provisioning (or manage them in the SSO Setup Suite) to rotate or revoke tokens. The documented way to validate a token against a project is via the SCIM HTTP API, requiring the format

Authorization: Bearer ProjectId:AccessKey

with the base URL

<https://api.descope.com>

(or your custom domain). For further information, you can check these resources: SCIM Management | Descope Documentation, SCIM Management API | Descope Documentation, Configure Okta SSO as IDP | Descope Documentation.

@Itai Ben Natan do you use the SSO setup suite for your customer? In that case you have there the api url and the generate scim token with a full guide per IdP

SCIM was configured in the past and stopped working all of a sudden for this customer. What could've changed?

Can it be that they revoked the scim key?