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 by the ServiceNow Application certification team.  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. 
I can think of two other approaches 

 1. If I give 'oauth_admin' role to the non-admin users, I’m able to read the record from the oauth_entity_profile table.
2. I can also add ACLs with operation="read"  on the oauth_entity_profile table for custom application roles.

But I am not sure if the certification team would approve of either. 

Can anyone help with me with suggesting how to resolve this issue. .Any help is greatly appreciated..

Thanks,
Krithika

[Mark Manders]

Why not add the step of letting the customer create an integration user for this, that can be used for the integration? Adding the 'admin' role to that user would resolve all of your issues, with just one instruction in the install guide. 

Most custom 3rd party apps with integration capabilities do it like this. Adding the oauth_admin role to non admins can cause issues with other integrations, because you don't know what your customers already run on that role and the certification team doesn't really like it when you add ACLs to OOB tables. 

You can also try if read cross-scope privileges will work, but I think adding an integration user would be the safest step.