Hi Okta team,
We’re seeing repeated issues across multiple customers where SCIM provisioning from Okta to our system stops working unexpectedly with an Unauthorized error, even though no changes were made on either side of the integration.
Our setup:
- Our SCIM integration uses long-lived OAuth2 tokens (10 years) that we generate and expose to the customer.
- We store and authenticate these tokens using Doorkeeper, and we do not expire, revoke, or rotate them unless the customer explicitly triggers a regeneration.
- In affected cases, I’ve confirmed that the SCIM token currently stored in our system remains present, valid, and correctly linked to a service account. I can’t confirm its exact status at the moment the error occurred, but there is no logic that would have invalidated it on our side.
The problem:
- Okta returns an Unauthorized error for previously working tokens, often triggered when a new user is provisioned, or after an unpredictable interval (e.g., 24 hours, 2 weeks).
- Customers report that no SCIM requests reach our servers when this happens.
- The issue consistently resolves only after the customer regenerates the SCIM token or reconfigures the integration.
What I’m trying to understand:
- Why Okta might stop sending or honoring a previously working SCIM bearer token
- Whether there are known conditions (e.g. silent permission changes, background credential refresh) that could cause the SCIM provisioning setup to silently fail
I’m new to the team and am currently working on getting access to a sandbox account so I can test our SCIM integration directly, but in the meantime I’d really appreciate any guidance or diagnostic steps I can take to help our customers reduce downtime and better understand what might be causing these provisioning failures.