Re: RFC: Keycloak project presentation

Stian Thorgersen <sthorger@...>

Keycloak does indeed have built-in support for MFA, but it is currently limited to one-time passwords (HOTP or TOTP). It is possible to extend Keycloak to add additional custom MFA mechanisms and we have community users that use SMS, hardware tokens, etc. with Keycloak.

That being said we are aware of limitations here which will be addressed in the near future. The limitations are mainly lack of additional built-in types (SMS, email, backup, etc.) as well as support for users to have choice between multiple mechanisms.

Until recently we have not actually seen much demand to go beyond one-time password support, but with WebAuthn becoming an official web standard there is now a lot of demand for it. It is a high priority to the Keycloak team to deliver improvements in this area as well as WebAuthn support and we are aiming to have this available in the next few months. We also have several community contributors working on this together with us, one group is working on a WebAuthn library for Java ( and corresponding authenticator for Keycloak ( - this will be added directly to Keycloak in the future), another group is working on addition to authentication flows to allow for choices of MFA mechanisms.

In summary our plans are:

* Add support for admins to be able to manage what MFA mechanisms should be available
* Add support for users to configure multiple mechanisms through account console and selecting a default. During login users will be prompted for the default, but have choice to use an alternative
* Add support for WebAuthn to be used as a 2FA mechanisms in addition to password, and also a primary authentication mechanism for passwordless experience

More details can be found in our design brief for WebAuthn here The brief on application initiated actions is also relevant ( There will be two more related design briefs coming soon, one on passwordless experience for WebAuthn and another on extensions we are making to authentication flows (a contributor from the community is currently working on a proposal for this).

I hope this clears your concerns around MFA, if not I'm happy to discuss it further.

On Tue, 9 Apr 2019 at 19:56, Christopher LILJENSTOLPE <cdl@...> wrote:

Sorry I could not make the call today, but I did want to raise some concerns I have had over Keycloak.  One is the fact that, at heart, it is still a login/password system.  There is some ability to add MFA, but right now it is not really part of the standard mechanics, as far as I can see, and certainly does not allow multiple MFA capabilities - which is rapidly becoming a requirement and 'expected' behavior of an auth system.  I know there are issues open to look at this, but it seems as if there is no consensus within the keycloak community as to how to address those capabilities/requirements.

Without a clear path to enable more modern authentication practices, I'm pretty sure I wouldn't be able to support (I'm non-binding) adoption.


On Tue, Apr 9, 2019 at 8:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
The Keycloak project presented today:

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox

Anyways, wanted to move the discussion to the mailing list.

Chris Aniszczyk (@cra) | +1-512-961-6719

Co-Founder & CTO, Solutions
cdl@... | @liljenstolpe | @liljenstolpe
Follow us: Blog  | Twitter | LinkedIn

Zero Trust Network Security & Continuous Compliance for Modern Applications

Join to automatically receive all group messages.