search

istio-ecosystem / authservice

Move OIDC token acquisition out of your app code and into the Istio mesh
Apache License 2.0
216 stars 60 forks source link

Other flows particularly client credentials flow(machine2machine) #237

Open brackend opened 1 year ago

brackend commented 1 year ago

A micro services environment with for example sts services

nacx commented 4 months ago

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 , if we take the premise of no cookies, means that the client application must anyway read back the response to somehow read the access token and include it in further requests. Otherwise, for every client request, there would be an access token exchange with the IdP by the authservice. Requiring the client app to do this is not that different than letting it implement the flow itself.

I would like to get some insights here about the use cases and the expected experience.