dex
dex copied to clipboard
dexidp
Document that Public Clients are not expected to have a secret
Preflight Checklist
- [X] I agree to follow the Code of Conduct that this project adheres to.
- [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
- [X] I am not looking for support or already pursued the available support channels without success.
Version
2.31.2
Storage Type
etcd
Installation Type
Official container image
Expected Behavior
When performing a Device Code Authorization flow (as defined in the spec: https://datatracker.ietf.org/doc/html/rfc8628#section-3.1), the flow should complete correctly and return an authorization response.
Actual Behavior
Dex returns an Invalid Client error at the last stage of the authorization flow if the original request did not include a Client Secret because of this line: https://github.com/dexidp/dex/blob/master/server/deviceflowhandlers.go#L287 .
Steps To Reproduce
- Set up Dex with any OAuth 2.0 provider
- Perform a Device Code Flow request using any spec-conformant library (like https://github.com/cli/oauth)
Additional Information
The official RFC for this flow specifies that the client_secret is not a required field (or even an optional one) for this authorization flow.
My suggestion is that we forgo checking the client secret for clients that are Public. This works because spec-conforming libraries won't send it anyways because they are meant to be used with Public clients.
Configuration
No response
Logs
No response
Updating this issue to reflect the discussion in https://github.com/dexidp/dex/pull/2540
We just hit the same problem, and I don't think we have any good workaround. We made the mistake of creating the client as confidential even though we intended to use it as a public client, and while we can change it to make it public, we currently cannot remove the secret without breaking existing tokens & applications.
It seemed to me that the closed PR was the perfect fix for us. Dex accepting (and checking) a secret in the device flow seems to violate the specification, and we certainly would like to use oauth2 libraries that are spec-compliant.
@nabokihms On the linked PR you mentioned:
One approach to resolve the issue is to ignore secrets for public clients, but it will be a breaking change. I think we can just add a notice to the doc about public clients' nuances.
I don't quite understand how it's a breaking change to no longer check the secret during the device flow (since clients that do pass it by mistake would continue to work), but even if it is, can it be maybe gated behind a feature flag? Maybe --rfc-compliant-device-flow?
