There are 2 main reasons
For an OAuth2 client to access "protected" services, it needs a token that it can use to authenticate the user that drives it. This means that the user needs to provide their authentication credentials to the system somehow. There are [multiple ways][fn:grant-types] for the authentication/authorisation server to grant the client (e.g. GN2) the token it needs in order to access the "protected" resources.
For a client-facing client, the only available grants are:
I have implemented both the [Authorization Code][fn:auth-code] and the [Password Grant][fn:passwd-grant] in GN2.
I intend, once we have verified the basic operation of the auth system in a user-facing context, to actually upgrade to the [PKCE][fn:pkce] grant for better security.
The Authorization code works as follows:
The third step necessitates that the authorisation server (GN3) provide a UI for the user to provide their authentication credentials.
For a client (e.g. GN2) to access the authorisation server and/or the "protected" resources, it needs to be registered with the authorisation server in the first place.
This implies we need a UI to allow the admin to register new clients as they are needed. In this context, we will soon need the QC App to become a client to the authorisation server (GN3) and API server (also GN3) to limit who is allowed to add data to the system.
At this point, I do have to note that it is possible to provide a CLI client to do this, and get rid of the HTML UI. I had to make a decision on which UI will be easiest to understand for the admin (Zachary and possibly Dr. Williams) for registering the clients. I went with HTML.
The CLI client will need to authenticate, and get a token, then use that token in the client-registration process - which means there is state (storing the token) - which means implementing some sort of session-handling to store and use the token for the client-registration step.
The other option is to give the CLI client direct access to the database, but you would still need the user to authenticate themselves (to prevent randos from registering clients willy-nilly).