Summary
Currently kube-bind uses a confidential OIDC client, which requires a clientSecret to be stored and distributed.
By moving to a public client with PKCE (Proof Key for Code Exchange, RFC 7636), the clientSecret can be removed entirely.
Motivation
Raised in the context of #474 (Keycloak OIDC integration blog post): if we move to a public client, we can remove clientSecret from kube-bind's OIDC configuration, simplifying the setup and eliminating a secret that operators need to manage.
Public clients with PKCE are the recommended approach for CLI and native apps per RFC 8252 and are supported by all major IdPs (Keycloak, Dex, Auth0, Okta).
Proposed Changes
- Remove
clientSecret from OIDC configuration
- Implement PKCE flow in the CLI:
- Generate
code_verifier (random 32-byte base64url string) and code_challenge (SHA-256 of verifier)
- Include
code_challenge + code_challenge_method=S256 in the authorization URL
- Exchange authorization code with
code_verifier (no secret needed)
- Update documentation and blog posts to reflect the simpler setup (no client secret required)
References
Summary
Currently kube-bind uses a confidential OIDC client, which requires a
clientSecretto be stored and distributed.By moving to a public client with PKCE (Proof Key for Code Exchange, RFC 7636), the
clientSecretcan be removed entirely.Motivation
Raised in the context of #474 (Keycloak OIDC integration blog post): if we move to a public client, we can remove
clientSecretfrom kube-bind's OIDC configuration, simplifying the setup and eliminating a secret that operators need to manage.Public clients with PKCE are the recommended approach for CLI and native apps per RFC 8252 and are supported by all major IdPs (Keycloak, Dex, Auth0, Okta).
Proposed Changes
clientSecretfrom OIDC configurationcode_verifier(random 32-byte base64url string) andcode_challenge(SHA-256 of verifier)code_challenge+code_challenge_method=S256in the authorization URLcode_verifier(no secret needed)References