With the: https://{{$self[“subdomain”]}}.service-now.com/oauth_auth.do’ URL but i would like to auth to the: https://{{$self[“subdomain”]}}.service-now.com/oauth_token.do’ as i need the access token.
Thats my problem i dont have a username and password, hence I want to use that second option: oauth_token.do for the auth URL.
I can call it directly with the same Client ID, Client Secret and put the URL to the above (the same one in the auth provider options) and i get a token.
As a former ServiceNow developer, I feel your pain. I’ve had these discussions with clients many times.
Your client’s request for direct oauth_token.do access is viable and it simplifies ongoing connections, however, in platforms like n8n, we don’t have the flexibility to easily modify the ootb authentication/authorization flows.
n8n default ServiceNow credentials seem to be using a one-time oauth_auth.do grant to get the token then and oauth_token.do to refresh it when it expires. It is a far more secure approach but not very convenient when you are trying to provide a service to a third party with it. The other option is Basic authentication but i doubt your customer will be happy with it.
You can try explaining to them you are using an automation platform for rapid development and stability and it support just Basic authentication and “1 timme OAuth password grant”
Alternatively, your options are all extremely labor intensive, introduce security risks and are potentially very unstable:
HTTP Nodes: Manually build all ServiceNow API requests. (Complex and potentially unstable.Requires integrations with Secret storage services or hardcoding secrets into your code too)
Custom Credential: Copy and modify the default ServiceNow credentials to create a custom credential type for direct oauth_token.do access. (Complex, should be possible but not entirely sure how and if ServiceNow nodes will be able to use these credentials.)
If it was me I would play the “security risk” card. It is totally true and ServiceNow customers are obsessed with security since they pay a lot for a corporate system and probably have sensitive and important data in it.
Sorry for the essay but it’s just a complex issue with no straighforward solution.
Hope this helps.
I just wonder, would it be possible to use current ServiceNow credentials to obtain n8n credentials and afterward change the password on ServiceNow? As for google accounts it works.
I am confused as to why N8N asks for the client_id and secret still but then does the one-time ouauth)auth to grant the token if we already have the data needed to hit the oauth_token directly?
I will go ask and ask for a “Service style” user as well, but considering the clientid and secret work in postman i may have to build my own http nodes!
Not entirely sure how n8n connection with ServiceNow works, it was just my guess because i saw both servicenow oauth endpoints in the servicenow credentials.ts you shared.
What i meant when I said 1 time grant is more secure is in context of having to store the secret somewhere else outside of the default n8n credentials which are encrypted.
Also to get back on topic what @Ruslan_Yanyshyn is suggesting is to ask them to do the grant once and if they are concerned with security they can change passwords. If you can confirm they will never have to do the grant again this might be a good solution.
Also his initial suggestion in my opinion is the correct one, using the built in capabilities of n8n is probably the most reliable way to go, anything else will require big amount of effort and won’t be more reliable.
For anyone else with this issue, I got them to change the grant type to “Password” and this fixed it. However I feel N8N should be able to deal with the grant type of “token” as we can work with both options, just calls that other endpoint that is already defined.
It is totally true and ServiceNow customers are obsessed with security since they pay a lot for a corporate system and probably have sensitive and important data in it.
