Skip to main content

Salesforce app returns unauthorized_client after the Fen-X callback URL is registered

Applies to: All Fen-X tenants and regions running the Fenergo CLM for Salesforce App

A customer sets up the Fenergo CLM for Salesforce App in a new environment. They reach step 8 of Installing the Fenergo CLM for Salesforce App and ask Fenergo to register their Salesforce callback URL:

Fenergo registers the URL. When the customer starts the auth flow from Salesforce, it fails with:

Sorry, there was an error : unauthorized_client

Because the error appears straight after the URL was added, it looks like the URL was registered wrongly. Usually it wasn't.

Cause:

Fen-X rejects the request because of how the Fen-X client is set up (Management > Security > Client Management). There are two possible causes:

Wrong grant type (main cause). The Salesforce login is a redirect flow: the user is sent to Fen-X, logs in, and comes back to the callback URL. That flow needs the Authorization Code grant type. A client set to Client Credentials isn't allowed to use it, so Fen-X returns unauthorized_client.

Missing scopes. The client doesn't have all the scopes the Salesforce app asks for.

The error doesn't say which one is wrong. Fix both before retesting. Fixing the scopes alone won't help if the grant type is still Client Credentials.

Resolution

Resolution

Support asked the customer for the Client ID of the Fen-X client used by Salesforce, because it wasn't in the original callback-URL request.

Customer replied with the Client ID. They added that they had seen this error before, and a missing scope had caused it then.

Support shared a screenshot of the client setup from Management > Security > Client Management.

Customer replied that some scopes were missing. They asked support to compare it with their working client in the UAT tenant.

Support aligned the scopes with the UAT client and asked the customer to retest.

Customer replied that the unauthorized_client error was still there. They asked support to compare every tab, not just Basics. They also noticed the UAT client used the Authorization Code grant type, while the new client used Client Credentials.

Support asked CBO to make the client match the UAT client exactly, including the grant type, and asked the customer to retest.

Customer replied that it was working.

Fix: set the Fen-X client's grant type to Authorization Code and give it the full scope list (offline_access openid profile tenant Fenergo.Nebula roles refresh_token), matching the working UAT client.

Triage shortcut

If you see unauthorized_client straight after a callback-URL request, don't start with the redirect URI. Check the Fen-X client's grant type first (it must be Authorization Code), then its scopes. Compare it with the customer's working client in another environment.

Prevention

Make the Client ID a required field on the callback-URL request form.

Update step 8 of the install guide to say the Fen-X client must use Authorization Code and have the full scope list.

Did this answer your question?