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

Bill Burke bburke at redhat.com
Tue Aug 18 08:39:54 EDT 2015


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.

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


More information about the keycloak-dev mailing list