[keycloak-dev] Pluggable client authentication, Support for client authentication with signed JWT

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 2:39:54 PM
> Subject: Re: [keycloak-dev] Pluggable client authentication, Support for client authentication with signed JWT
> 
> SAML client console pages have a way to import/export keys/certs.  You
> may be able to reuse/merge with that.
> 
> Maybe we should figure out how to merge client and user
> authenticators/flows.

Should we really merge them? Will they not always be different enough to warrant having them separate?

> 
> On 8/18/2015 2:58 AM, Marek Posolda wrote:
> > I've sent PR https://github.com/keycloak/keycloak/pull/1545 for
> > #subject. Few main points:
> > - Authentication of OIDC clients is now pluggable. I've added
> > ClientAuthenticationSPI and some support classes like
> > ClientAuthenticator . There is also new flow type
> > ClientAuthenticationFlow as there are some differences between
> > authenticating clients and users (ie. for clients you don't have
> > ClientSession available etc).
> >
> > - There is new builtin flow "clients" added automatically, which can be
> > seen in "Authentication" tab in admin console . By default it has 2
> > executions:
> > -- Traditional authentication with client_id and client_secret
> > -- Authentication with signed JWT . It works in a way that client
> > generates JWT and signs it with his private key . Keycloak then verifies
> > signature with public key attached to the certificate corresponding to
> > client . Related specifications: [1] and [2] . I've implemented 6.1 and
> > 6.2 from the [1], which means that clients are able to authenticate
> > themselves for retrieve service accounts (ie. "grant_type" is
> > "client_credentials" ), but also authenticate themselves for all other
> > backchannel requests (code-to-token, refresh token etc)
> >
> > - In "Credentials" tab in admin console for Client is table with
> > available authentication mechanism. Admin needs to choose "Client Id and
> > Secret" or "Signed JWT" . For signed JWT he can either:
> > -- generate keypair + certificate and download his private key into JKS
> > or PKCS12 keystore file
> > -- upload the certificate corresponding to his existing private key .
> > In both cases is Client's private key not saved in Keycloak DB as
> > discussed in other thread last week. So just the client is exclusive
> > owner of his private key and when he loose it, he needs to generate and
> > download another one.
> >
> >
> > Possible remaining work:
> > 1) Adapters support?  I am thinking about adding simple pluggable SPI
> > for client authentication on adapter side. It will be ServiceLoader
> > based and it will choose client authentication mechanism based on the
> > credentials provided in keycloak.json in webapp. For example when there is:
> >
> > "credentials": {
> >       "secret": "password"
> > }
> >
> > it uses traditional clientId and clientSecret like now.
> >
> > When there is:
> >
> > "credentials": {
> >       "jwt": {
> >           "keystoreFile": "classpath:keystore/keystore.jks",
> >           "keystoreType": "JKS",
> >           "storePassword": "secret",
> >           "keyPassword": "secret",
> >           "tokenExpiration": 10
> >       }
> > }
> >
> > it will authenticate client with signed JWT . WDYT?
> >
> >
> > 2) Example, docs, polishing, maybe adapter tests . But most of automated
> > testing is done already. I've added ClientAuthSignedJWTTest for testing
> > signed JWT and CustomFlowTest for testing custom client authentication
> > flow.
> >
> >
> > ETA for 1 and 2 are maybe 2-3 days of work. I will show more on the call
> > on Thursday. WDYT?
> >
> > Marek
> >
> >
> > [1] https://tools.ietf.org/html/draft-ietf-oauth-assertions-01
> > [2] https://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>