Secure applications with Keycloak authentication tool

Developers can speed up the application development process without sacrificing security using open source authentication tools, such as Keycloak. With this authentication tool, developers can offload access tasks and digital identity data storage. They can include single sign-on, Lightweight Directory Access Protocol integration, multifactor authentication and more in applications. For system admins, Keycloak provides a centralized identity and access management console. The console reduces access management complexity when a company has hundreds of applications.

Red Hat developers Stian Thorgersen and Pedro Igor Silva wrote Keycloak -- Identity and Access Management for Modern Applications. The book provides a step-by-step guide on connecting the Keycloak authentication tool to applications. It introduces developers and system admins to important IAM concepts, standards and more.

In this interview, Thorgersen explains Keycloak development, where it fits in the IAM market, passwordless possibilities and more. "After starting the Keycloak project about eight years ago, I always thought it would be helpful to have a beginner's book that developers and systems admins can use to start their journey with Keycloak," he said.

Editor's note: The following interview was edited for length and clarity.

Why did you, Silva and others develop Keycloak around IAM?

Stian Thorgersen: When we started working on Keycloak, there were mostly traditional IAM products available. They were either more heavyweight software or frameworks to build your own thing. There wasn't anything in between that was application developer-focused and identity- and more service-oriented. We decided to make it open source partially because that's Red Hat's philosophy, but we also wanted all developers to have access to a simple authentication tool.

Since the release of the Keycloak authentication software, what other similar developer-focused identity products have been released?

Thorgersen: One option is Auth0, which started roughly the same time as we began development of Keycloak. That SaaS product is closed source and proprietary, but companies don't have to self-host and manage it. Then, there is Ory Hydra, which is a lightweight, goal-based option. Hydra requires more building and gluing together but is an option for companies interested in customization. They each have their upsides and downsides.

Where do you suggest readers start when learning about common IAM protocols?

Thorgersen: Everyone should start with OAuth [Open Authorization], which is the simplest. But that doesn't give you authentication; rather it's a 'let me access something else on behalf of the user.' It's an easy-to-understand flow and has less optional features and query parameters. Once readers understand that, they can focus on OpenID, which is an added layer on top of OAuth. It adds the ability to authenticate a user with an application and have a standard way of representing what the user is to the application.

In Chapter 6, you review application types that work with Keycloak. Are there any that cause more friction than others?

Thorgersen: That has a complex answer. The OAuth and OpenID specs are heavily reliant on web flows, HTTP and the system browser. And a lot of the security levels come in terms of redirecting to Keycloak or your IDP [identity provider] and not letting applications collect credentials. You can achieve an SSL solution without exposing user credentials to individual applications. With web technologies, like REST APIs, single-page applications or a server-side application fits quite naturally and works well with Keycloak. Developers will find it more difficult when connecting the IAM tool to native applications. The challenge will be integrating it and providing a smooth user experience. We focused more on the server side but do provide some SDKs for certain environments. But we don't have integrations for every environment out there. That's where we look to third-party IDPs that are built into the different frameworks.

Click here to learn more about
Keycloak -- Identity and
Access Management for
Modern Applications here.

More on Keycloak -- Identity and Access Management for Modern Applications

To learn more about the book before buying, read an excerpt from Chapter 6 here.

One trend in IAM is continuous verification. Does Keycloak have the capabilities to provide this if a company wants stronger verification?

Thorgersen: We label that as 'adaptive authentication,' but that's just a different name for the same thing. We are headed in that direction with step-up authentication [prompt users to provide additional credentials for higher access]. It will give companies the ability to go up and down roles and access based on different authentication levels [and] then, in the future, make it more adaptive.

Keycloak has individual login sessions to individual applications, forcing users to go back to Keycloak to reestablish a new set of tokens. It is good practice to have shorter sessions, forcing users to reauthenticate after a set time. Keycloak can do some of this already, such as timing out a user if they're inactive. If the application is deemed critical, the company can request standard open and leave parameters for authentication.

The security industry has a lot of interest in passwordless IAM options. Where does Keycloak fit into that journey for organizations?

Thorgersen: Keycloak has WebAuthn [Web Authentication] support, so you can use that for passwordless authentication or as the second factor. Keycloak also supports Kerberos. If you're logged in to the desktop with Kerberos, you can delegate authentication that way. Other authentication methods include delegating to other IDPs.

With regards to passwordless, I think that WebAuthn is important for the future. It gives the industry a way to standardize. However, it's still early days. It can be a little bit clunky when using it beyond the security key experience. We need to work on that a little bit and improve the flow for users. However, if some users don't want to be passwordless, it's a little difficult and remains a pain point.

What would you like to see from the IAM community in the near future?

Thorgersen: I would like to see self-sovereign identity be more of an evolution of what we have today rather than a complete rewrite of everything. I think that the standards, specifications and approaches are complex and will be difficult for people to roll out. The requirements of having SDKs for individual applications is also complex and hard. So, building on top of OpenID Connect and extending on that, then building more of a self-sovereign kind of strategy.

On the other side, I think that access management could use improvement. I think it remains an unsolved problem today. I don't think role-based access control is great. Making a centralized authorization product for current workloads is complex enough. More IoT devices and SaaS services for multi-cloud and hybrid cloud make it even more difficult. Finding a solution for centralized organization that performs well even at scale could use a lot of investment for new ideas.

About the authors
Stian Thorgersen has worked at Arjuna Technologies building a cloud federation platform and at Red Hat, looking for ways to make developers' lives easier. In 2013, Thorgersen co-founded the Keycloak project with another developer at Red Hat. Today, Thorgersen is the Keycloak project lead and is also the top contributor to the project. He is a senior principal software engineer at Red Hat, focusing on identity and access management.

Pedro Igor Silva has experience with open source projects, such as FreeBSD and Linux, as well as Java and J2EE. He has worked at an ISP and as a Java software engineer, system engineer, system architect and consultant. Today, Silva is a principal software engineer at Red Hat and one of the core developers of Keycloak. He studies IT security, specifically application security and identity and access management.