Unable to convert a curl OAuth request for PagerDuty into a REST OAuth request

[bllewellyn]

I have a curl command running on my laptop that obtains an OAuth token for PagerDuty modeled after their Obtaining Access to Token doc:

curl  POST \
  https://identity.pagerduty.com/oauth/token \    
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id={REDACTED_CLIENT_ID}" \
  --data-urlencode "client_secret={REDACTED_CLIENT_SECRET}" \
  --data-urlencode "scope=as_account-us.{REDACTED_SUBDOMAIN} incidents.write incidents.read"

This works great, but when I attempt to convert this into REST for ServiceNow I get an error saying "Method failed: (/oauth/token) with code: 401 - Invalid username/password combo"

var body =
    'grant_type=client_credentials' +
    '&client_id={REDACTED_CLIENT_ID}' +
    '&client_secret={REDACTED_CLIENT_SECRET}' +
    '&scope=as_account-us.{REDACTED_SUBDOMAIN} incidents.write incidents.read'

var request = new sn_ws.RESTMessageV2();
request.setEndpoint('https://identity.pagerduty.com/oauth/token');
request.setHttpMethod('POST');
request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
request.setRequestBody(body);

var response = request.execute();
var responseBody = response.haveError() ? response.getErrorMessage() : response.getBody();
var status = response.getStatusCode();

gs.info(status)
gs.info(JSON.stringify(responseBody))

I have re-entered the creds umpteen times and tried several variation of this using setStringParameter instead of passing in a body, concatenating the URL instead of passing in a body, encoding the string and passing it to the body/URL, converting it to JSON, changing the Content-Type, ... but they get errors saying that the grant_type is missing so those are not passing in the proper format for PagerDuty.  I also tried creating an OAuth profile and I get the same error, bad creds.

The above script is the closest I have gotten but it is erroring with "Invalid username/password combo" as if the x-www-form-urlencoded is messing with the text in the client_id or client_secret.

I have kinda hit a wall with it so I'm hoping someone has done something similar and can point me in the right direction.

[Tushar]

HI @bllewellyn 

Please try using below code and let me know if it works for you ---

var params = new GlideScriptParams();
params.addEncodedQuery('short_description=Network');
params.add('caller_id', '6816f79cc0a8016401c5a33be04be441'); // Sample User ID
params.add('category', 'Hardware');
params.add('subcategory', 'Printer');
params.add('u_requested_for', '6816f79cc0a8016401c5a33be04be441'); // Sample User ID

var request = new sn_ws.RESTMessageV2();
request.setHttpMethod('GET');
request.setEndpoint('https://your-instance.service-now.com/api/now/table/incident');
request.setRequestBody(params.toString());

var response = request.execute();
var responseBody = response.haveError() ? response.getErrorMessage() : response.getBody();
var status = response.getStatusCode();

gs.info(status);
gs.info(JSON.stringify(responseBody));

Please, don't forget to mark my answer as correct if it solves your issue or mark it as helpful if it is relevant for you!

Regards,
Tushar

[bllewellyn]

Thanks for the response, Tushar. GlideScriptParams was a new one on me, so I tried to find some documentation on it before running it. I tried googling it first, with no hits. Then I did a code search for it and couldn't find any examples used in any OOB ServiceNow code. 
I decided to try just and declare it as a variable in a background script before adding it to my code, but it doesn't look like a defined API. 
Script: 

var params = new GlideScriptParams();

Output:

Evaluator: com.glide.script.RhinoEcmaError: "GlideScriptParams" is not defined.
   script : Line(1) column(0)
==>   1: var params = new GlideScriptParams();

 Tried it with global. as well but again returned undefined. 

[bllewellyn]

Less of a fix and more of a workaround, but the issue is resolved!

We were correct in our assumption that REST was encrypting the special characters in the token incorrectly. I manually encrypted it by replacing the special characters with the ASCII equivalent, and it is working as expected.

Big thanks to @_ChrisHelming for pointing me to a tool to help dissect the payload and find where the error was.