Best practice for promoting OAuth Application Registry (oauth_entity) records across instances

AlexAlvarez
Tera Contributor

18 hours ago - last edited 18 hours ago

Hi all,

 

I'm securing our Inbound REST APIs using OAuth 2.0 and have created the necessary Application Registry (oauth_entity) records in our Dev instance. I now need to move this configuration to Test and eventually Production, but I'm unsure of the safest approach.

 

If I move the oauth_entity records via Update Set, the client_id and client_secret would be identical across Dev, Test, and Prod — which seems risky from a security standpoint (shared credentials across environments, and the client_secret being encrypted with an instance-specific key that may not decrypt correctly elsewhere).

 

The alternatives I'm considering:

 

  1. Create a brand new oauth_entity record natively in each instance (same scopes/grant type/config, but a unique auto-generated client_id/client_secret per environment).
  2. Move the record via Update Set and then manually update the client_id/client_secret on each target instance afterward.
  3. Keep the same client_id/client_secret across all instances.

 

My instinct is that option 1 is the correct approach, but this adds manual overhead for every promotion and requires re-configuring consumers with new credentials per environment.

 

Has anyone dealt with this scenario? Is there an official ServiceNow-recommended pattern for handling OAuth Application Registry records across environments (e.g., excluding oauth_entity from Update Sets, using Connection & Credential Aliases, or a post-deployment script to regenerate secrets)? Any guidance, KB articles, or lessons learned would be greatly appreciated.

 

Thanks in advance!

Alex Álvarez
0 Helpfuls
  • 140 Views
1 REPLY 1

Danish Bhairag2
Tera Sage

18 hours ago

@AlexAlvarez ,

 

I would recommend creating a separate OAuth Application Registry in each instance rather than promoting the oauth_entity record through Update Sets. This ensures each environment has its own unique client_id and client_secret , which is a better security practice and avoids any issues with encrypted secrets across instances.

Treat the Application Registry as environment-specific configuration, while using Update Sets only for application logic (REST APIs, scopes, scripts, etc.). Although it requires a little extra setup, it provides proper environment isolation and makes credential rotation much easier.

 

As per ServiceNow documentation for best practice its not mentioned anwhere that we cannot move it via update set but its good to have seperate creds based on instances.

 

Thanks,

Danish Bhairagdar

0 Helpfuls