Client Credentials OAuth Application User

s-jacobs
Tera Contributor

Hello!

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 now for brevity. To use the client credentials grant type, one only needs to specify the grant_type (of "client credentials"), client_id, and client_secret to the oauth_token.do endpoint - simple!

Using a catalog item and flow designer, we can also automate the provisioning of the application registry, which creates the client id and secret - awesome!

There's one configuration that I can't get past - the OAuth Application User that must be specified in the Application Registry (see KB1645212). I understand why it's there based on ServiceNow's security model. I also understand that records created or updated via API actions still need to have a "sys_created_by" and "sys_updated_by" for audit trails on those records. 

However, having to maintain a sys_user record, which is what the OAuth Application User is, in combination with client credentials just seems...odd. User records need to have passwords rotated to comply with security policies. As a ServiceNow admin, I don't want to have manage password rotation. If a team integrates with ServiceNow, but using client credentials they don't specify a username and password, then the user record is just "extra." All they really care about is the client id and secret, and that their REST operation works. 

Typically speaking, teams will want to test their integrations in non-prod environments as well. Which means now we are not only managing one account, but several, which adds considerations to clone operations. 

Looking for your experience, community! How have you handled this scenario?




1 ACCEPTED SOLUTION

Maik Skoddow
Tera Patron
Tera Patron

Hi @s-jacobs 

 

the entire ServiceNow platform is built on the concept to have sys_user records bound to transactions for managing access and security of the related operations.

And when selecting an integration user in the application registry it doesn't mean ServiceNow will authenticate that user but only connect the inbound integration request with that user. For this reason you don't need to maintain a password for these sys_user records. You can enter any random characters and then forget them. So no need to rotate the password.

 

Maik

View solution in original post

2 REPLIES 2

Maik Skoddow
Tera Patron
Tera Patron

Hi @s-jacobs 

 

the entire ServiceNow platform is built on the concept to have sys_user records bound to transactions for managing access and security of the related operations.

And when selecting an integration user in the application registry it doesn't mean ServiceNow will authenticate that user but only connect the inbound integration request with that user. For this reason you don't need to maintain a password for these sys_user records. You can enter any random characters and then forget them. So no need to rotate the password.

 

Maik

Thanks @Maik Skoddow. That makes sense, since the user isn't being utilized for authentication, a case can be made with security teams that password rotation for those "User" accounts is not necessary.