Webservice connector (Authentication: OAUTH2) Test Connection Failure

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Hi

We are using webservice type connector and Authorization is OAUTH2,grant type is client credentials, by using these we are trying to establish the test connection , but we getting the below mentioned error.

We have tried from postman side for generating the token, token is getting generated, but while trying from the Sailpoint side we are facing the issue while trying to esablish connection.

Could anyone help regarding the issue we are facing.

error:
Exception occurred in Test Connection. Error: Exception occurred while generating access token: Unable to generate access token. Response returned: {“message”:“Only authorization header OR client ID/client secret should be provided.”}

Thanks,
Akash

2

Could you kindly provide a screenshot of the configuration setup?

3

Try adding the below in the Application object via debug pages:

<entry key="oauth_headers_to_exclude" value="Authorization"/>

4

Hi @Abhisinha89 ,

Thankyou for insight, however we are still getting the same issue.

Thanks,
Akash

5

Hi Akash,

Can you share the screenshot of your connection details.
Also, You can try this approach -
Using postman, Fetch the access token and refresh token.
In the Sailpoint connection details section - Provide the Refresh token, client_id and client_secret. It should work.

6

Hi Amit,

Since the configuration in remote desktop, we are not able to share the configuration. But the configuration is same as standard.

So coming to your approach - you are suggesting that provide the ‘grant type’ as ‘Refresh Token’ and provide the token url, client_id, client_secret and refresh token.

Here how can we generate the refresh token with client credentials. can you give some reference.

Thanks in advance.

7

@logesh_venki -

In OAuth 2.0, the Client Credentials grant type is designed for machine-to-machine (M2M) communication, where the client (usually a backend server) is authorized on behalf of itself, not a user. This differs from user-facing OAuth flows like the Authorization Code grant.

The Client Credentials flow typically does not involve issuing a refresh token. Refresh tokens are generally issued when the OAuth flow involves user authentication (as with the Authorization Code or Password grant types), where the user’s session might expire but you still want to refresh the access token without asking the user to log in again.

Here’s why the Client Credentials grant type doesn’t provide a refresh token:

  1. Machine-to-Machine (M2M): Since no user is involved, the client can simply re-authenticate using its client ID and secret whenever the access token expires. This removes the need for a refresh token.
  2. Security: A refresh token for a machine-based application could increase security risks if compromised. Instead, the client can directly request new tokens as needed.
  3. Statelessness: The Client Credentials flow assumes the client has persistent access to its credentials, so it doesn’t need to “refresh” a token.

How Client Credentials Grant Works:

  1. The client sends a POST request to the token endpoint, using its client ID and secret.
  2. The server responds with an access token and typically no refresh token.
  3. When the access token expires, the client repeats the process and requests a new one.

The error message you’re encountering in Sailpoint IdentityIQ suggests a misconfiguration during the OAuth connection setup for your web service. The key part of the error is:

“Only authorization header OR client ID/client secret should be provided.”

This indicates that the OAuth configuration is attempting to authenticate with both the Authorization header and the client_id/client_secret parameters at the same time, which violates the API’s authentication requirements. Most OAuth implementations require one of the two approaches:

  1. Using the Authorization header: This approach uses HTTP Basic Authentication, where the client_id and client_secret are sent as part of the Authorization header.
  2. Providing client_id and client_secret in the request body: This sends the client_id and client_secret as form parameters in the body of the token request.

However, your current setup is likely attempting to use both methods simultaneously, which is causing the API to reject the request.

Steps to Fix the Issue

As per my knowledge - It is a standard supported auth method for the Web Services connector. For more details refer to the Web Services connector guide document.

In the various Connector Operation configs such as Account/Group Aggregation etc, add a Header called “Authorization” with a value of “Bearer $application.accesstoken$”.

Let me know if it helps.

1 Like
8

Hi Amit,

Thank you for help!!!

We have followed the same thing for configuration. However application is not storing the access token and $application.accesstoken$ contains ‘bearer’ value.

So we followed the below, it works for us.

  1. Add header key as ‘Authorization’ and value as ‘$application.accesstoken$’ for each operarion.
  2. add the below attribute in application xml via debug. this will get the access_token from oauth_token_info and store in accesstoken.
    <entry key = "accesstoken" value="access_token"/>
2 Likes
9

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