SCIM Token Becomes Unauthorized Unexpectedly Across Multiple Customers

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.

There are 2 different ways to configure the Okta SCIM client with a Bearer Token

  • Supply the token value directly in the config.
  • Configure the SCIM integration to do an authorization code flow

Can you confirm which of the above methods is being used?

If it is the first this should work like any static credential and not change until manually edited.

If it is the second there might be a chance that Okta would need to re-authorize to get a new token after a certain amount of time, I will check.
It is recommended to return a refresh_token along with the access_token. As long as the refresh_token does not expire then Okta will periodically get a new access_token and there shouldn’t be a need to re-authenticate.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.