Support Client Credential Flow for machine-to-machine auth

[ZackButcher]

istio-ecosystem/authservice#237

[nacx]

In order to properly implement this, we need to nail down the use cases.

The client-credential grant flow is basically meant for machine-to-machine, so we should assume no browser and, consequently, no cookies involved in the process.

In this flow the client application basically exchanges the clientId/clientSecret for an access token. The clientId/clientSecret are sent in the Authorization header, and the access token is returned in the response body. From there, the client uses that access token to talk to the target application.

When it comes to the authservice, we need to decide where those clientId/clientSecret are configured. There are two main options:

1. clientID/clientSecret configured in the client app:
   In this case the client app itself would be sending the clientid/clientSecret in the header, and would have to process the response to get the access token, to use it in subsequent requests. This is effectively implementing the entire client credential grant flow, and authservice seems to be not needed here.
2. clientID/clientSecret configured in the authservice:
   In this case, the clientId/clientSecret would be preconfigured in the authservice config file. When the client app makes a request to the target service, the authservice intercepts it. If the request does not contain an access token, the authservice could request one using the preconfigured clientID/clientSecret, and add it to the request headers. If a token is present in the request, the authservice could check the token expiration, and if OK, just allow the request as-is.

Option 1 means authservice is not involved, so no work is needed here.

Option 2 has some caveats that need to be thought through:

• If the clientID/clientSecret has to be preconfigured in the authservice config, then the authservice instance can probably not be shared. Either:
  • There can't be a single deployment of the authservice that is used as the main ext_authz to enforce OIDC, or there could be a single instance if, for every application and clientID there was a specific OIDC section. This, however, would require each config to be under a Match and the current configuration only allows header-based matching.
  • When using the client credential grant, the authservice must be deployed as a sidecar, by each app team, so that applications use the local authservice and that one is configured with the local clientId/clientSecret.

I may be missing something, but these are the main things that come as doubts when thinking about implementing this flow.
In order to make the right decisions and design how to properly support this credential grant, we need to have more clarity and a much better understanding of the real use cases we want to enable.