Is OAuth for inbound requests to ServiceNow feasible without a lot of manual intervention?

[Wesley Falcao]

Referring to the OAuth 2.0 for inbound REST requests as mentioned here- 

https://www.servicenow.com/community/developer-blog/oauth-2-0-with-inbound-rest/ba-p/2278926

https://www.servicenow.com/community/now-platform-forum/how-to-use-oauth-authentication-in-serviceno...

The basic premise is - "OAuth is a specification that allows users to delegate access to their data without sharing their username and password with that service".

- https://auth0.com/blog/everything-you-wanted-to-know-about-oauth-2-but-were-too-afraid-to-ask/

If an application wants to make inbound REST API calls to ServiceNow as a particular user, then it needs to use the OAuth Access token. However, in the above links, the end user's username and password is required to generate this token. So if OAuth is to be done properly, the access token generation step cannot be performed by the application (since no one other than the end user should know their own username and password). 

The end user needs to generate the access and refresh token and then provide the refresh token to the application. The application can then use the refresh token to get a new access token. However, when the refresh token expires, we are back to the same manual procedure again - 

1. As the end user, make an API call to https://<serviceNowInstance>.service-now.com/oauth_token.do/ and generate a new refresh token

2. Provide this new refresh token to the application. The application needs to be edited to accept the new token either through a UI interface or an API call. 

This is not practical in production systems, especially for high volume and when the refresh token is close to expiration. Even a little bit of delay in obtaining the new token can cause outages. 

However, as it stands, there does not appear to be an automatic solution than to have the application ALSO store the end user's username and password so that it itself can generate the refresh and access tokens. But this is not OAuth, since the application now knows the end user's username and password, which it should not as per the OAuth protocol. 

[Katie Irvine]

I have exactly the same challenge - following to see if the Community can help.

[Mitchell Rose]

If you want "automatic" refresh tokens for a role account then, yes, you must store some credentials. That's the way OAuth works. Were it a "real" user, the system would be expected to prompt for re-authorization. You, per your company policy, can configure both access and refresh token expiration durations; do so wisely.