We are currently experiencing intermittent login issues on Community.  The team is actively working on a fix.

Wasif
Tera Guru
Tera Guru

In the integration space, there's a concept of machine to machine and client to machine integrations.

ie when there is no user interaction to trigger the API- its basically a machine talking to another machine and then there are those that a client triggers.

 

Machine-to-Machine

From ServiceNow’s perspective, if you look at it, all the scripted APIs that we have are in a way a machine to machine interaction- where we have authentication and ACLs coming into picture.
And note here, which is a key difference- when we are calling these APIs- they need to be authenticated upfront as they have not been authenticated- so a basic auth or OAuth can be used to determine the authenticity of the invoker, along with the ACLs in place. 

 

Example in ServiceNow 

  • So in ServiceNow- Scripted Rest acts as a machine to machine integrations, where the authentication and authorization become important coz to say the user has not been authenticated ever before the API call 

 

 

Client-to-Machine
This is something that I was not able to wrap myself in the past, coz we have been dealing with monolith architectures (ServiceNow platform or other Enterprise apps) where everything is encapsulated and sometimes we overlook the client and server demarcation. 

 

So now wrt ServiceNow- we do have widgets in Service Portal and so is Ajax.
Thing to note for this type of integration is – the user is already authenticated on the UI as he is in a UI session, so when an API gets trigger you probably don't need a direct authentication rather some indirect one – say a user token and session which can be validated for authenticity and in addition to it- we can apply the authorization layer as well- say the ACLs for particular table etc. 

 

Example in ServiceNow 

  • Here we have the widget client controller and the Server script. So when the client does a server.get/ server.update-> we may overlook that this is an API call – the API is handled in ServiceNow and can be seen in the network tab  
  • So the user is already authenticated on the UI- these apis- can take in token of the user session and the user token in the header- to validate the user, instead of basic auth etc
  • Additionally authorization can/ needs to be checked for 2nd layer validity; and ACLs can be enforced using GlideRecordSecure for ex. 
  • The handler logic, ie in this case the server script (of the widget) needs to also validate other user data or permissions etc to avoid manipulation via an intercept attack
  • Another example is the Ajax calls- where a client is calling a client callable Script Include. Another ServiceNow internal API gets called for which the Script Include becomes the handler; and to secure intercept attack- we can have Client callable SI ACL,apart from other things if we want to put for validation 

 

Why important to understand is because we need to treat the handlers as independent API logic as they can be intercepted, hence proper validation in the API handlers should be done as much as possible to avoid ‘man in the middle’ attacks