[keycloak-dev] Opinion on how secret the OIDC "client secret" should be?

[Marc Boorshtein]

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 at tremolosecurity.com
Twitter - @mlbiam / @tremolosecurity