Personal Access Token for security-enabled WebAPI

Problem Statement

When WebAPI AtlasRegularSecurity is enabled, requests to WebAPI require an Authorization token as part of the request as described on the wiki: https://github.com/OHDSI/WebAPI/wiki/Security-Implementation#signing-requests-to-protected-methods. This is cumbersome when using the WebAPI from applications other than ATLAS since obtaining the Authorization token is only possible when accessing WebAPI via ATLAS today. As an example, we have R code that aims to use WebAPI to access design elements, etc which cannot participate in the authentication process enabled by ATLAS/WebAPI

Background

To obtain the Authorization requires the security handshake with one of the configured security providers to ensure that authentication is completed. The authentication process may vary between providers (i.e. AD, oAuth, etc) and may require redirection to 3rd party sites for authentication, etc. Doing this in the context of R is not practical since it would require a browser to do this work.

Ideas to move forward

I like the idea of having a personal access token as is done for accessing the GitHub API and is described here in these articles:

• https://happygitwithr.com/github-pat.html.
• https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line

The advantage of this is that we can insist on the proper security mechanisms through ATLAS and use that as mechanism to create & store a personal access token.

Please consider this as a working idea vs. a solution - I think the more we can find a workable solution to this for 2.8 it will help us think through a more robust solution for 3.0.

Start with the WebAPI Security Implementation wiki section on signing requests and trace the AtlasRegularSecurity authentication flow and configured security providers. The issue is a working idea rather than an implementation plan; done would require an agreed personal-access-token design that lets non-ATLAS clients authenticate without the browser-based provider handshake.