SCIM Token Becomes Unauthorized Unexpectedly Across Multiple Customers (Continued)

Questions SCIM
1

I originally asked this question in this thread:

The bug was deprioritized on our side but has since been affected numerous other customers so I still need help finding a solution.

To summarize the original thread, 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.

The developer that responded in that thread asked which approach we are using to configure the Okta SCIM client with a Bearer Token. I’ve confirmed that use a static bearer token for authentication, not the authorization code flow. When an admin enables SCIM provisioning, the system automatically generates a long-lived OAuth access token using the Doorkeeper OAuth library and provides it for configuration.

Since the recommended solution in the other thread doesn’t apply to our situation, does anyone have any other advice for what we should look into?

2

How long-lived are we talking here? Is there any possibility that these tokens are becoming invalidated or expiring?

3

We use this method to generate the token in our system:

  def generate_long_lived_access_token!
    token_creator = Doorkeeper::OAuth::ClientCredentials::Creator.new
    token = token_creator.call(service_account.oauth_application, "", { expires_in: 10.years.from_now })
    self.token = token.plaintext_token
    save
  end

The token is valid for 10 years, and we do not rotate, revoke, or expire it unless the customer explicitly regenerates it in our UI using this dedicated endpoint:

def regenerate_token
  app_install.generate_long_lived_access_token!
  render json: { data:   app_install.token }
end

There is no automatic “refresh token” or “re-authorization flow” in our Okta integration that could be causing the tokens to become invalidated or expired in the short term. We have this setting enabled in our doorkeeper config

# Issue access tokens with refresh token (disabled by default)
use_refresh_token

But from what I’ve read that should not apply to ClientCredentials since they don’t support refresh tokens.

As far as I’m aware, the only way the token should change is if the customer manually pastes in a new token value or it expires after ten years. But the customers are having to replace invalid tokens every two to three weeks so there is definitely something wrong somewhere

4

And what is the authentication method being used for the SCIM integration on the Okta side: Is it Bearer, Header, or OAuth?

5

We use a static bearer token in the HTTP Authorization header. The token is generated on our side via Doorkeeper’s client-credentials flow that I described above. When receiving requests, our SCIM controllers check that the bearer token in the header matches an active token for the company’s Okta app install. From what I understand, all SCIM requests originate from Okta and include whatever bearer token is currently configured in the app’s provisioning settings. From what I’ve seen in past investigations, it looks like Okta is still sending SCIM requests when the issue occurs, but those requests fail with a 401.

Is there anything that could cause Okta to stop sending the Authorization header or replace the stored token value without the customer realizing? For example after certain admin changes, app re-assignments, or profile mapping edits? Though whatever the trigger is, it would have to be something that happens relatively often across multiple orgs for the problem to be this widespread

6

I can’t think of any reason for there to have been a change to the auth on the Okta side without an admin making updates to this aspect of the application configuration. If a static token was provided, then we should continue sending the same token.

What do you see on your side when those 401 errors occur? Are you able to tell if there was a change to the auth being sent or otherwise determine the cause of the error?

7

Hey @andrea, just following up on this. The problem has been difficult to investigate because the customers fix it immediately by regenerating a new token, and we’ve been having issues accessing our sandbox to reproduce the issue. The sandbox should be setup by next week so I’ll try to find the answers to your questions then.

Thank you for your help!

1 Like