Oauth 2.0 webservices connection failing to generate token

Having some issues setting up a OAuth 2.0 connection with the Web Services connector. Keeps throwing the following error:

“Exception occurred in Test Connection. Error: Exception occurred while generating access token: Unable to generate access token. Response returned: java.net.SocketException: Connection reset”

in PostMan and our other automation engine (Okta Workflows), everything works but not sure how Sailpoint ISC is sending the token request that it keeps erroring. I’m doing the following:

  • grant type: client_credentials
  • client_id: client ID
  • client_secret: client_secret
  • oauth request parameters: i used a “audience” key and a value our devs gave me

In the HTTP Operations page I have the following:

  • 3 header key/value pairs according to what our devs gave me

I dont see any difference between the Postman and Sailpoint setup, not sure why Sailpoint keeps throwing a connection reset error.

Hey Lia, I saw this thread about a similar issue in IIQ, Message: java.net.SocketException: Connection reset, HTTP Error Code: 0

Another thing which might be worth looking into is seeing if any of the auto generated headers in Postman is missing in the call which ISC is making. Not sure about the Socket Exception but i have had similar issues where the API call wasnt working in ISC because of some missing header which is usually auto generated in Postman

@lcha1 you need to upload the certificate of the application in the virtual appliance certificate folder .another option you can try is to run the curl directly in the va and check if it works there or not .If you are getting SSL error there also you can connect with your network team to allow this url from the VA

Hmmm I don’t think so. In Postman and Okta Workflows, we’re not doing any SSL cert validation and it works fine.

Yeah I saw that article and did try some of the things in there but it didn’t work. For some reason Postman console is not logging anything I do so I can’t verify what headers are being created/sent. I checked the headers section in the call and used the usual “content-type”, “authorization” etc etc but still doesn’t work.

hi @lcha1,
Instead of using OAuth 2.0 as the authentication type use “Custom Authentication”

In the Http Operations create a operation called Custom Authentication using “Custom Authentication” as operation type. Also make this as the first operation

Now give these details

In the body provide your grant type, client id and secret and audience

In the Response Information put Root Path as $ and success codes as 2**
Finally in the response mapping map the accesstoken

I hope this works for you.

1 Like

@lcha1 can you share your connection setting screenshots? We can help you then

Hi @udayputta , I am also using custom Auth for one of my sources, using it the exact same way you mentioned and then I created test connection operations and using a normal get call for that using access token from result of custom in the headers of test connection but I am getting 401 unauthorized, the same thing is working from Postman or if I hardcode the token in test connection then also it works, could you please suggest

Are you storing accesstoken in customaccesstoken variable. In the test connection check if you have to provide Bearer as prefix to your accesstoken. As you mentioned you are are seeing 401 unothorized. Check if you have provided correct details in your custom auth operation. If possible share the cust auth operation which you have created.

Yes, I am storing it in customaccesstoken. the details are correct as the same thing is working from POSTMAN. PFB the SS for reference to config done.

Your Response Information has and extra period after $ is that correct?
Also instead of storing it in customaccesstoken can you store it in accesstoken which is already encrypted and an OOTB attribute.
You can then refer the accesstoken in the similar way $application.accesstoken$.
I also suspect that you need to put “Bearer” as prefix in the value. Can you validate that in postman once.
If you prefer to use custom access token attribute then you might need to add that in the source as encrypted list

1 Like

Thanks Uday, making it to accesstoken instead of customaccesstoken and removing . after $ from response info made it worked.

Thats great ! Glad it worked. Can you mark the reply as solution as it will help others aswell.

I know this is already solved, but for anyone else troubleshooting the same or a similar issue, I’ve found it very useful to change the OAuth token request address to a site that can receive and display the contents of your HTTP requests, such as https://webhook.site (free) that way you can see exactly what body and headers IdentityNow is sending. Then you can compare with the Postman console to see where the discrepancies lie.

Don’t forget to set a fake clientID and clientSecret when doing this so you’re not sending access to an API key with admin privileges to a system outside of your control. Alternately you can immediately rotate your credentials after testing.