ServiceNow Client Credentials Grant – Why Do We Still Need an OAuth Application User?

victor85pau
Kilo Contributor

I like the idea of having inbound (to ServiceNow) REST integrations start to use the client credentials grant type for several reasons, which I'll leave out for brevity. To use this flow, you only need to provide the grant_type (client_credentials), client_id, and client_secret to the /oauth_token.do endpoint — simple!

Using a catalog item and Flow Designer, we can even automate the provisioning of the Application Registry, which creates the client ID and secret — awesome!

But there’s one configuration that’s proving to be a blocker: the OAuth Application User that must be specified in the Application Registry (see KB1645212). I understand this exists because of ServiceNow’s security model — records created or updated via API still need sys_created_by and sys_updated_by values for auditing.

That said, having to maintain a sys_user record just for this purpose feels... odd. Especially in combination with the client credentials flow, where no username/password is being supplied. User records typically require password rotation and follow identity policies. As a ServiceNow admin, I don’t want to manage password rotation for what is essentially a service identity.

0 REPLIES 0