Salesforce ECA Authentication – Random 401

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, ,
1

Hi everyone,

We recently migrated our Salesforce source in SailPoint ISC to the new Salesforce External Client App (ECA) authentication method.

Since the migration, we are randomly getting the following error during provisioning:

[ConnectorError] Create account operation failed. Request failed with status code 401

The issue appears to be intermittent. If we retry the operation or manually click Authorize on the source, it usually works again.

We suspect this may be related to the refresh token, especially since the behavior seems to indicate that the existing token is sometimes no longer accepted.

I have already seen this related discussion: Salesforce ECA asking reauthenticate every time - SailPoint Human Fabric (SHF) / SHF Discussion and Questions - SailPoint Developer Community

The suggested workaround there is to disable refresh token rotation. However, this is not possible for us due to our security policy.

Has anyone experienced the same intermittent 401 Unauthorized issue with Salesforce ECA authentication?

Any guidance would be appreciated.

Thanks!

2

Hi @baoussounda

Start by checking one thing on the source right after a failure: does the Last Authorized Date disappear?

3

If the date stays and a plain retry succeeds, the refresh token is still valid and the failure is at access-token level. Might be the easier problem to solve. Check two items under the ECA’s Policies (not Settings) in External Client App Manager:

  • Refresh token policy: in this thread, the cause was a validity period shorter than the aggregation schedule
  • Session timeout: this sets access token lifetime, so a short value means more refreshes and more chances to hit the case above

Otherwise, if it has disappeared, means Salesforce has revoked the token itself. It might be a max token issue. Salesforce keeps at most five active refresh tokens per user per External Client App and silently drops the oldest when a sixth is issued. If a client later presents a dropped or rotated-out token, Salesforce treats it as a security event and invalidates every token and session for that user across all clients.

4

Thanks @Pratyush27

  • The last Authorized Date always appears.

  • We’ve already checked the refresh token policy, and we don’t see any expiration lifetime configured for the refresh token. It only appears to be refreshed when it is revoked.

In parallel, I’ve opened a SailPoint Support ticket to investigate this further.

5

So the refresh token is fine and the 401 comes from the access token. Could you check two things and share the results here?

  1. Session timeout: in the ECA’s Policies, the session Timeout Value (if blank, the org’s Session Settings value applies). This is the access token lifetime.
  2. Failure timing: for three or four failed operations, the time of the failure and of the previous provisioning call, plus the integration user’s Login History around each failure.

I am thinking if each 401 comes after a gap longer than the timeout, and a successful login follows right after, the connector refreshes only after a call is rejected. That would point to a connector issue.

In any case a support ticket at this point is the right call. Do share the resolution when you get one

6

@baoussounda change this in salesforce to option one

image
image796×505 46.9 KB

7

@schattopadhy this option was already changed in our environnement and we have the first option

image
image1005×635 70.4 KB

8

Thanks @schattopadhy. That matches what @baoussounda confirmed earlier: the refresh token is valid until revoked, so the refresh token policy is not the cause. I guess the open question is still the access token.

Try this:

  1. In the ECA’s Policies, set the session Timeout Value to 15 minutes.
  2. Provision one account, wait 20 minutes, then provision another.
  3. If the second call fails with 401 and a retry succeeds, the connector is sending an expired access token and refreshing only after the call is rejected.
9

Hello @baoussounda, did you get a chance to fix this ? We have the same error on our side.

10

Hello @ragavi87688 ,

We still have an open ticket with SailPoint Support, and we have planned a debugging session with them in the coming days.

They have recommended the following steps and provided some recommendations. However, we have already aligned with them on these points, and our Salesforce team has informed us that they cannot update the application for certain actions because it is a SailPoint-managed application.

Currently our work around is to Re-Authorize manually in ISC.

Message from Sailpoint support :

Begin

Even though the screenshot confirms that “Refresh token is valid until revoked” is selected under the External Client App (ECA) OAuth Policies, Salesforce will still throw err=invalid_grant: token validity expired under several specific platform conditions.

Further troubleshooting steps:

  1. Integration User Pre-Authorization Assignment:

Context from Screenshot: Permitted Users is configured as “Admin approved users are pre-authorized”.
When this policy is active, Salesforce strictly requires that the Profile or a Permission Set assigned to the integration user be explicitly linked to the ECA. If it is missing or was modified, Salesforce rejects token refreshes with invalid_grant.

Action:

  • In Salesforce, go to Setup → External Client App Manager (or Manage External Client Apps).

Open the SailPoint Identity Security for Salesforce app.
Under the Policies section, verify Manage Profiles and Manage Permission Sets.
Ensure the Profile or Permission Set assigned to the dedicated ISC Integration Service Account is explicitly added.
2. Salesforce 5-Token Limit per User per App (Multi-Environment Conflict)

Salesforce enforces a strict limit of 5 active OAuth refresh tokens per user per connected app / ECA.
If the same Salesforce integration user is used across multiple ISC tenants (e.g., Sandbox/Dev, Test, Prod), multiple ISC sources, or external tools (like Postman or scripts), each new authentication generates a new refresh token and silently revokes the oldest one.

When ISC subsequently attempts to refresh its token, Salesforce returns invalid_grant: token validity expired.

  • Ensure a dedicated Salesforce integration user is used solely for this specific ISC tenant and source.

In Salesforce, navigate to Setup → Connected Apps OAuth Usage (or check the Integration User’s profile under OAuth Connected Apps). Revoke stale/duplicate sessions.
3. Re-Authorize in ISC:

  • Go to ISC → Admin → Sources → [Salesforce Source] → Connection Settings / Authentication.

Click Re-Authorize / Connect and complete the OAuth login flow using the dedicated integration account.
Save and run Test Connection.
Re-test the failed provisioning operation (Create Account).

End
11

Hello,

After several discussions and troubleshooting efforts with SailPoint Support, we finally received the following feedback:

"Our Connector Engineering team has identified this as a connector defect and created a tracking item to address this use case.

Please find the ticket details below and follow it for future updates: CONETN-5800."

Thanks

12

Hi,

We are encountering the same thing and have also create a case to support to push for a fix. In the meantime, we are manually re-authorizing the ECA authentication.

Do you have a retry mechanism in place for the access provisionning or account creation that failed on provisioning ?

On our end, we re-request the access for the end-user but it’s painful.

Regards,

13

Hi @davidtrn ,

For now, we don’t have any automated retry mechanism in place. When provisioning fails due to the ECA authentication issue, we have also to manually re-authorize also the authentication and re-trigger the access request for the affected end user.

As mentioned, this is quite cumbersome, especially when it impacts multiple users.

Hopefully, the connector defect tracked will be addressed quickly with a permanent fix.

Thanks.

14

Thanks for the feedback.

Too bad the Salesforce connector doesn’t have retry mechasnims like the Web service connectors.