How can non-admin users call REST Message with OAuth2.0?

[KrithikaV]

HI,

I have been asked to use GlideRecordSecure instead of GlideRecord in scripted REST APIs. All my scripted REST APIs use oAuth2.0 authentication with grant type as 'client_credentials'.

For non-admin roles (i.e. roles created for our custom application), I'm unable to read the sys_id of the oauth entity profile record. Hence, I'm unable to invoke REST APIs. 

const gr_oauth_profile = new GlideRecordSecure("oauth_entity_profile");

var  oauth_profile_record = gr_oauth_profile.get("oauth_entity", "xxxxx"));

if (oauth_profile_record)    //always returns false for non-admin users

        r.setAuthenticationProfile("oauth2", oauth_profile_record.getUniqueValue());

The statement : if (oauth_profile_record)  always returns false when I login using my application's custom non-admin roles. So, I'm unable to set the Authentication Profile. 

 If I give 'oauth_admin' role to the non-admin users, I’m able to read the record from the oauth_entity_profile table.
However, how can I retrieve the oauth_entity_profile record  using the GlideRecordSecure object without the 'oauth_admin' role for non-admin users. 

or how are REST APIs using oAuth2.0 invoked under non-admin user's login.

Any help is greatly appreciated..

Thanks,

Krithika

[Rafael Batistot]

Hi @KrithikaV 

May you try via ACL 

This is the recommended approach for maintaining security and is consistent with the purpose of using GlideRecordSecure. It allows non-admin users to fetch the specific records they need without elevating their overall privileges. 

Steps:

1. Navigate to System Security > Access Control (ACL) in the filter navigator.
2. Create a new read ACL on the oauth_entity_profile table.
3. Set the Operation to read.
4. In the Requires role section, add your custom, non-admin role. 
5. Create another read ACL on the oauth_credential table. This is often required to read the associated token details.
6. Set the Operation to read.
7. In the Requires role section, add your custom, non-admin role.

With these ACLs in place, your GlideRecordSecure query will succeed, as the non-admin user now has explicit permission to read the required OAuth records.

[KrithikaV]

Hi @Rafael Batistot,

Thank you for the suggestion. I was wondering if the ServiceNow certification team might disapprove as this would  lead to my application's custom roles

having full read access to all the records in the oauth_entity_profile table. 
Any idea if ServiceNow certification team is ok with ACLs being added to the oauth_entity_profile table for custom application roles?

Thanks,
Krithika

[JackieZhang]

you can set the sys_id in sys properties, then you do not need to read the oauth_entity_profile

[Rafael Batistot]

@KrithikaV 

You are right if you grant your custom roles full read access to all records in oauth_entity_profile, that will likely be considered a red flag in certification, because:

• It violates the principle of least privilege.
• It can expose sensitive integration configuration.
• The certification team tends to reject apps that alter access to system tables unnecessarily.