You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for an issue that matches the one I want to file, without success.
Problem Description
When using the OIDC connector Dex should support a secure method for distributing a common configuration file that could be used by multiple instances of a given application. Presently this is not possible as the OIDC connector requires both a ClientID and ClientSecret leading to either the distribution of the ClientSecret to all application instances or a unique ClientID for application instances. The former is insecure and the later is unfeasible with significantly large numbers of application instances.
Proposed Solution
OIDC classifies client applications into two categories, Confidential and Public. Dex presently behaves only as a Confidential application and thus requires a ClientID and ClientSecret. I propose that support for Public be added as an option to the OIDC connector.
I believe all that is required is:
Add a new configuration option to enable Public mode for connectors.
When public mode is enabled allow for an empty ClientSecret
When public mode is enabled add a S256 Challenge option when generating the OIDC AuthCodeURL.
Use the appropriate verifier when running 'Exchange' later on in the flow.
The majority fo the actual work is handled in the downstream golang oidc code and was added in April of this year:
ifc.Public {
verifier:=oauth2.GenerateVerifier()
opts=append(opts, oauth2.S256ChallengeOption(verifier))
// Add state and verifier to a connector level cache with a short expiration. Referenced in Exchange later.
}
FWIW - I have a separate golang application where I have added a variant of the suggested improvement and have verified its use with Okta as an upstream OIDC provider.
cameronbrunner
changed the title
Support Upstream OIDC Servers without a ClientSecret
Support Upstream OIDC Providers without a ClientSecret
Nov 15, 2023
Preflight Checklist
Problem Description
When using the OIDC connector Dex should support a secure method for distributing a common configuration file that could be used by multiple instances of a given application. Presently this is not possible as the OIDC connector requires both a ClientID and ClientSecret leading to either the distribution of the ClientSecret to all application instances or a unique ClientID for application instances. The former is insecure and the later is unfeasible with significantly large numbers of application instances.
Proposed Solution
OIDC classifies client applications into two categories, Confidential and Public. Dex presently behaves only as a Confidential application and thus requires a ClientID and ClientSecret. I propose that support for Public be added as an option to the OIDC connector.
I believe all that is required is:
The majority fo the actual work is handled in the downstream golang oidc code and was added in April of this year:
golang/oauth2#603
golang/go#59835
Some sample code.
Add something like this to the LoginURL function (
dex/connector/oidc/oidc.go
Line 253 in e41a28b
And this to HandleCallback (https://github.com/dexidp/dex/blob/e41a28bf27225ab503eb9feef4feedd03bb4ac71/connector/oidc/oidc.go#L291C18-L291C18)
Alternatives Considered
Additional Information
Discussion on Confidential and Public OIDC applications - https://auth0.com/docs/get-started/applications/confidential-and-public-applications
The text was updated successfully, but these errors were encountered: