Broken API response to authentication token

[Francesco Cipol]

When trying to get an API access token from https://<myinstance>.service-now.com/oauth_token.do the request returns a broken response.

See below for the literal response. It includes non-utf8 characters and is truncated.

{
	"access_token": "89fteujz-jckwom9JlNWW1_TigY36SXNFm9xgyYNQlfWVGKbO82dej81cd-c3bZCR9M7xPxKLXTI9rHB1oXt8g",
	"refresh_token": "﷞﷟﷒ab0e43da87b81110a60f7f59dabb35e8﷬﷔1﷬﷭ckrIhPb9GbKwcIIhn1YWsA==tHH-k1yju3Y5DPf0VgFiDEdyFMHpz_jCshVyp_uUM5BeZK_uCO-nS0ThLv-2VviRh74QF_sBjf_SWLYPi1omsVUvY-cguNceS6EPEE4ETtA17ZU8E4C3B8BS5K_iKq5Iq58auGcT﷮﷯",
	"scope": "useraccount",
	"token_type": "Bearer",

Any ideas what might be happening?

The only special circumstance is that the instance was reclaimed a few days ago, but I managed to restore it.

All data and users was still there and working.

Thanks & regards

[Tony Chatfield1]

Hi, I don't see this behaviour in my PDI which was reset within the last 7 days to and is running
glide-sandiego-12-22-2021__patch1-03-02-2022

The refresh token also seems to be abnormally long, not truncated?

Do you get this result in multiple tool-sets or if tested from different PC/laptop?
If not then perhaps the issue is local configuration?

[Francesco Cipol · Accepted solution]

Thank you for your input Tony!

It turns out that the Oauth Client Secret got corrupted at some point - probably during the reclaim/restore process. I noticed that and updated it with the previous, correct value, which was then accepted by API requests. That's when I was getting the corrupted auth answer above.

It seems that the corruption of the Secret was deeper than just the value itself. In a hunch, I went and created a new set of OAuth credentials, and these are working fine.  🙂

Not sure if this was a very unusual case, but I hope that this entry helps other people in the same situation.

Thanks & regards,

Alfonso