SCIM PATCH/DELETE fails on SAML enterprise connections — non-URL-safe id in CREATE response

Get Help
,
1

Issue

We have SCIM provisioning enabled on a SAML enterprise connection. SCIM CREATE operations succeed, but all subsequent PATCH and DELETE operations fail because Auth0’s SCIM endpoint returns a non-URL-safe id in the CREATE response.

What’s happening

When a user is created via SCIM, Auth0 returns the internal composite user_id as the SCIM id:

"id": "samlp|my-saml-connection|username"

This id contains pipe characters (|) which are illegal in URI paths per RFC 3986. When the upstream SCIM client (Okta, using Apache-HttpClient) stores this id and attempts PATCH or DELETE, it tries to construct a URL like:

PATCH https://<tenant>.us.auth0.com/scim/v2/connections/<connection_id>/Users/samlp|my-saml-connection|username

This fails with:

java.lang.IllegalArgumentException: Illegal character in path at index 94

The error occurs on the client side before the request is even sent. As a result:

  • PATCH and DELETE requests never reach Auth0
  • No error logs appear on the Auth0 tenant
  • User lifecycle management (updates, deprovisioning) via SCIM is completely broken

Expected behavior

Per RFC 7643 Section 3.1, the SCIM id field must be usable in URL paths since it’s used to construct resource endpoints. Auth0 should either:

  1. URL-encode the id value (e.g., samlp%7Cmy-saml-connection%7Cusername)
  2. Use the internal UUID instead of the composite user_id

Steps to reproduce

  1. Create a SAML enterprise connection with SCIM provisioning enabled
  2. Have the upstream IdP (e.g., Okta) create a user via SCIM POST
  3. Observe that Auth0 returns a pipe-delimited id in the response
  4. Attempt a SCIM PATCH or DELETE on that user — fails with illegal character error

Environment

  • Auth0 tenant: Development
  • Connection type: SAML (Enterprise)
  • SCIM client: Okta (Apache-HttpClient 4.5.10)
  • Auth0 tenant log event type for successful create: sscim

Impact

This blocks all SCIM user provisioning beyond initial creation for SAML enterprise connections. We cannot update or deprovision users via SCIM, which is a critical gap for enterprise customer onboarding.

1 Like
3

Hi @ben30,

Welcome to the Auth0 Community!

You have identified correctly that the error java.lang.IllegalArgumentException: Illegal character in path is occurring because the SCIM client (Okta) is attempting to use the Auth0 user_id as the unique resource identifier in the URL path.

That is why mapping the id is not the solution for SCIM Inbounding. It is noted in our Configure Inbound SCIM - Attribute mapping that:

The SCIM id and meta attributes cannot be mapped… The id value in SCIM responses is always set to the Auth0 user_id.

Because this field is immutable and hardcoded to the pipe-delimited user_id, the id itself can not be configured as the user’s identifier in this cases.

To bypass this, you must configure Okta to use the userName (which is URL-safe) as the resource identifier instead of the system id.

You can follow the instructions found in our Inbound SCIM for Okta Workforce SAML Connections documentation:

First, ensure that the userName attribute is mapped to a URL-safe field, such as email.

  1. In the Auth0 Dashboard, go to Settings > Mapping for your SCIM connection.
  2. Update the mapping to ensure userName uses the email:
{
  "scim": "userName",
  "auth0": "email"
}

In the Okta Provisioning settings for the Auth0 app:

  1. Locate the Unique identifier field for users.
  2. Change this setting from id to userName.

Okta will now construct the URL as .../Users/user@example.com instead of using the pipe-delimited ID. Since the email address is URL-safe, the IllegalArgumentException will be resolved.

We recognize that the use of non-URL-safe characters in the primary SCIM ID can create friction, but this is currently by design. If you would like so, you can create a Product feedback since this might be considered for a future change and our product team tracks these requests closely.

I hope this helps and if you have further questions please let me know!
Best regards,
Remus

1 Like
4

Hello,

If I do this I get this error -

image
image2240×1372 268 KB

5

I removed the 2nd mapping for email, is that correct? do I need to change the “SCIM attribute containing user id”?

6

Hi @ben30,

The change is correct, as mentioned in the documentation as well.

No, the “SCIM attribute containing user id” is correctly set to userName. This tells Auth0: “When a user logs in via SAML, look at the attribute which is designated as userName to identify them.” Since the userName is mapped to email, this ensures consistency.

Kind regards,
Remus