Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Other flows particularly client credentials flow(machine2machine) #237

Open
brackend opened this issue Jun 4, 2023 · 1 comment
Open

Comments

@brackend
Copy link

brackend commented Jun 4, 2023

A micro services environment with for example sts services

@nacx
Copy link
Collaborator

nacx commented Apr 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants