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

[Marc Boorshtein]

Reposting on Eric's behalf

On Sep 14, 2016 2:54 PM, "Eric Chiang" <eric.chiang at coreos.com> wrote:

> Thanks Marc for the cc,
>
> Just to give some background for the reasoning behind this.
>
> Today the Kubernetes API server trusts ID Tokens issued to a single
> client. Refreshing a token requires a client_secret, hence the flags Marc
> provided in his example. Though we don't have official recommendations
> about what the properties of the client passed in those flags should be
> there's two obvious ways of going about this.
>
> 1) Have each kubectl share a client secret. Some authorization servers
> provide mechanisms for declaring "public clients" to imposes restrictions
> on its capabilities. For example Google, when it assumes client_secrets
> aren't secret, restricts the redirect URLs for embedded apps to only
> localhost and a magic OOB, doesn't let it do incremental authorization,
> etc. Though as Marc noted this may have unintended consequences with
> providers who assume this doesn't happen.
>
> 2) Another option is for kubectl to utilize the "azp" claim in the ID
> Token[0], which allows clients to request ID Tokens on behalf of other
> clients. This means each kubectl gets its own client_id and client_secret,
> with each one requesting ID Tokens minted for a common client_id. However
> that capability isn't generally supported by OIDC providers, though Google
> does[1]. This is probably a more secure option, but the actual
> implementations differ so widely that it becomes hard to make a general
> statement.
>
> We'd be interested in knowing if either of these methods raise red flags
> when combined with keycloak.
>
> Eric
>
> [0] https://openid.net/specs/openid-connect-core-1_0.html#IDToken
> [1] https://developers.google.com/identity/protocols/CrossClientAuth
>
>
>
> On Wed, Sep 14, 2016 at 10:16 AM, Marc Boorshtein <marc.boorshtein@
> tremolosecurity.com> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/ee8823ba/attachment.html