KC Team, Eric Chiang from CoreOS (cc'd on this email) and I have been talking on the Kubernetes sig-auth slack channel about how secret the "client secret" in OIDC should be. The context for the question is that Kubernetes' OIDC implementation uses the id_token as the bearer token (as opposed to the access_token) to avoid a round trip. Since the id_token should be short lived the question of how to get a new one using a refresh_token. The current solution is to give kubectl the refresh_token, the idp discovery url and the client id and secret: kubectl config set-credentials --auth-provider=oidc kubectl config set-credentials --auth-provider-args=idp-issuer-url=( issuer url ) kubectl config set-credentials --auth-provider-args=client_id=( your client id ) kubectl config set-credentials --auth-provider-args=client_secret=( your client secret ) kubectl config set-credentials --auth-provider-args=refresh-token=( your refresh token ) This way kubectl can get a new id_token once the possessed one expires. The question becomes does giving the client_secret directly to users become a security issue since its now a shared credential? Some issues I see are: 1. Rotation becomes harder - how many people have this? 2. While you can't generate an access_token with just this secret, you CAN impersonate an RP so if your are monitoring which RPs are making requests an attacker could generate excessive requests for a single RP even if those requests fail 3. Since most IdPs will generate some kind of back-end record for a request if you have the client id and secret you could more easily do a DoS attack by flooding the server with authenticated requestes for authentication What are your thoughts? Google provides an example asserting that the client secret ISN'T secret (reading through it I think the example contradicts its self) https://developers.google.com/api-client-library/python/auth/installed-app Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein(a)tremolosecurity.com Twitter - @mlbiam / @tremolosecurity