OAuth2 client credentials support for OPAL Server

[scarlier]

Is your feature request related to a problem? Please describe.
The OPAL Client Configuration Variables currently only support sending static values to OPAL through the OPAL_CLIENT_TOKEN. However, our machine-to-machine communication relies on OAuth2 client_credentials, which cannot be implemented with a static token. As a result, we are unable to use the current authentication method provided by the OPAL Client Configuration Variables.

Describe the solution you'd like

OPAL Client
To provide more flexibility in authentication for the OPAL Client, we propose adding support for additional authentication methods to communicate with OPAL server. Specifically, we suggest implementing the ability to create additional tokens using either a Token or OAuth2 method.

To enable this functionality, we recommend adding new configuration variables:
OPAL_CLIENT_AUTH_TYPE
OPAL_CLIENT_AUTH_OAUTH_SERVER
OPAL_CLIENT_AUTH_OAUTH_CLIENT_ID
OPAL_CLIENT_AUTH_OAUTH_CLIENT_SECRET.

If the value "oauth" is found in the OPAL_CLIENT_AUTH_TYPE variable, the OPAL Client will send the client id and secret to the OAuth2 server using the client_credentials standard. The response will include a token with an expiration time. The OPAL Client will use this token to communicate with the OPAL Server and will cache it until its expiration before requesting a new one.

OPAL Server
On the OPAL server side, it needs some modifications to support other tokens than the ones it creates itself.

To enable this functionality, we recommend adding new configuration variables:
OPAL_AUTH_TYPE (default or oauth)
OPAL_AUTH_OAUTH_JWKS_ENDPOINT
OPAL_AUTH_OAUTH_ISSUER
OPAL_AUTH_OAUTH_SCOPE_CLIENT (the scope name that needs to be in the token for having “client” permissions)

The server can then use the OPAL_AUTH_OAUTH_JWKS_ENDPOINT for retrieving the public keys for validating the token.
The OPAL_AUTH_OAUTH_ISSUER for validating the correct issuer in the token
The OPAL_AUTH_OAUTH_SCOPE_CLIENT for validating that the scope name exist in the token to give permissions of type “client”

Because it uses web sockets it should accept the token from the client to validates against before sending data to the opal client
The client should be able to send updated tokens, so the server can validate against “fresh” tokens when required.

Summary
In summary, by making the suggested modifications to the OPAL server and client, it can enable support to a more diverse set of authentication methods. This is a valuable enhancement that will facilitate greater interoperability between systems and use of central authentication servers within the organization.

[asafc]

Also a great suggestion.

@shaulk @roekatz this is a bit complex since it affects core OPAL authentication, which we are currently dependent on. Even if this is optional, breaking this logic will have big implications. Let's do a discussion and revert back.

[asafc]

Hi @scarlier, your suggestion to move the authoritative server for authentication is good overall. By letting OPAL server trust a different service for issuing tokens, some of the complexities of managing tokens within OPAL might be lifted. We've put it in our OPAL backlog and we'll try to get to it soon.