Add support to the CHT api for new endpoint for OIDC login

[jkuester]

• The /medic/login/oidc endpoint should support GET requests with a code query param. The code should be the authorization_code coming from the OIDC Provider.
• This is the endpoint the OIDC Provider should re-direct back to.
• Add a new getOidc function in api/src/controllers/login.js that will handle the request and call through to code in the openid-client to validate the authorization_code.
• For a good authorization_code, the OIDC Provider should return an id_token containing the username for the authenticated user.
• Lookup the user's doc in _userand confirm oidc_provider value is set
• Generate a Couch session cookie for user and respond with valid user session.
  • This will require access to the Couch secret value which can be requested from the Couch instance. There is some code in the proxy auth PR that does this. I think we might be able to put that functionality for getting the secret into shared-libs/settings (or maybe that code is already sufficient for retrieving the secret value?).
• Add integration tests for the login controller

[benkags]

@jkuester please assign me this ticket

[jkuester]

@benkags Done!

[benkags]

openid-client (#9736.) is a typescript implementation. CHT api is in JS causing an incompatibility that I am not sure there is a way around. Having settled on Keycloak for the id provider #9737, settling on a Keycloak library seems like a good idea for this phase. Let me know!

keycloak-connect seems to integrate well with CHT so exploring that. I will look into keycloak-js as keycloak-connect is no longer being maintained.

[jkuester]

openid-client (#9736.) is a typescript implementation. CHT api is in JS causing an incompatibility that I am not sure there is a way around.

🤔 So, I don't think TS should be a problem here. In my experience, TS projects like this typically transpile everything down to JS files before publishing to NPM (along with the TS declaration files). Then the NPM package can be consumed by either JS or TS projects. Can you share the specific problems you are encountering trying to pull in openid-client as a dependency?

Having settled on Keycloak for the id provider #9737, settling on a Keycloak library seems like a good idea for this phase.

I think we should try to stick with a generic OIDC client library for our actual implementation code (since we want to support connecting to any valid OIDC provider and not just KeyCloak).

[benkags]

You are right @jkuester: code. I'll explore that. I agree with you using openid-client is perhaps the best approach for long term although I do not see harm in adopting a Keycloak implementation if it simplifies the implementation. This is especially because the design does not factor in supporting multiple OIDC providers right now and I anticipate some effort to support multiple OIDC providers at which point swapping out Keyclock for a generic implementation can be done.

[benkags]

I've got a working end to end flow using keycloak-connect in dbbbb7c which is good for validating the CHT login (creation of session & cookie); so, yay! I'll look into swapping out keycloak-connect and get back.

[benkags]

Work items break-down

• oidc flow implementation
• use openid-client library
• read the oidc provider configuration from app settings
• read oidc secret from couch secrets
• fail gracefully
  • if the oidc provider is not available
  • incorrect oidc config specified
  • cht user is not provisioned in CHT yet
• add tests