As of today, we’re thrilled to announce the launch of the new Phase Two Dashboard — a fully redesigned application for managing your Keycloak resources. This update goes far beyond a fresh coat of paint. We've rebuilt the experience from the ground up, introducing new capabilities, streamlined workflows, and deep infrastructure enhancements based directly on customer feedback. We've learned that the version of Keycloak we provide, enhanced by the Phase Two library of extensions, solves for the 95% Saas use-case and this release will allow our users to better take advantage of those features. Some features are available today and others will be made available in the next few weeks.

👉 Try it now

We are excited to announce that Phase Two has achieved SOC 2 Type 1 compliance! This milestone demonstrates our ongoing commitment to security, availability, and the protection of our customers’ data.

Learn more at trust.phasetwo.io.

As more companies build SaaS platforms, the need to serve multiple customer groups—or tenants—from a single system becomes critical. In the identity world, this means implementing multi-tenancy within your identity provider.

In this post, we’ll walk through:

• What multi-tenancy means in Keycloak
• The drawbacks of using multiple realms for tenants
• Why organizations are a better, more scalable approach
• How the Phase Two Organizations extension supports advanced use cases like theming, shared IdPs, and user membership
• How our implementation differs from (and improves on) the new native Keycloak organizations feature

We've written extensively about how to model multi-tenancy with organizations and how Phase Two's Organizations extension differs from the native implementation being undertaken by the Keycloak team.

All of Phase Two's hosted environments come standard with all of our popular extensions to make it easy to hit the ground running and cover 95% of all IAM use-cases.

As more companies adopt Keycloak for enterprise identity and access management, security is no longer just a back-end concern. One of the most frequent questions we hear at Phase Two is:

"Should I put a Web Application Firewall (WAF) in front of Keycloak?"

The short answer? It depends—but it's a smart question to ask.

In this post, we'll break down what Keycloak provides out of the box, explore common attack vectors (especially around authentication endpoints), and help you evaluate whether you need to add an external firewall or WAF to your deployment.

Keycloak supports passkeys and WebAuthn out of the box, with no plugin and, as of 26.7, no custom authentication flow. The thing worth knowing before you turn either on is that they are not one feature. Keycloak treats passwordless passkeys and WebAuthn-as-a-second-factor as two different credentials, registered by two different required actions, governed by two different policies. A user who has one does not have the other, and nothing in the admin console tells you so.

This post is the concept half: what passkeys are, how they relate to WebAuthn, how Keycloak models the difference, and the recovery and cross-platform problems that bite in production. For the configuration itself — every click, every default value, every failure mode — see the tutorial linked below.

SAML has a bit of a reputation. For many developers, it lives in that shadowy corner of the B2B internet where XML still rules and stack traces seem to go on forever. If you've ever had the misfortune of debugging a malformed <Assertion>, you know the pain. But here's the thing: it doesn't have to be a nightmare.

At Phase Two, we provide managed hosting and enterprise support for Keycloak, a leading open-source Identity and Access Management platform. And while OIDC has become the default for most modern applications, SAML is still alive and well—especially in enterprise environments.

This post is a gentle (and opinionated) introduction to what SAML is, how it works, and why it still matters particularly if you're implementing SAML SSO in Keycloak.

IdP Initiated Flow​

When implementing SAML for the establishment of an Identity Provider, two primary options are available:

1. Service Provider (SP) initiated
2. Identity Provider (IdP) initiated

The SP initiated flow is widely recognized by users due to its straightforward configuration, which is merely the exchange of some metadata. In contrast, the IdP-initiated flow is less intuitive and involves an additional step that may not be readily apparent to many users. The purpose of this blog is to elucidate the steps necessary to successfully execute the IdP-initiated flow. We will setup a full example

A fundamental understanding of SAML 2.0 and Keycloak is required to effectively follow the provided instructions.

Why consider Phase Two for your Managed Keycloak Provider​

When it comes to identity and access management, Keycloak has established itself as the go-to open-source solution for authentication, authorization, and user management. However, successfully integrating and maintaining Keycloak requires more than just hosting—it requires expertise. That’s where the difference between Phase Two and other hosting providers becomes clear.

In this post, we’ll explore why Phase Two should be in strong consideration for your Managed Keycloak provider, especially when compared to providers like CloudIAM, Elest.io, and Servana, who focus solely on hosting the standard build of Keycloak.

Part 4: Cost-Effectiveness of Open Source​

At the heart of every startup's decision-making process lies the bottom line. We’re in an economy where cost-cutting measures are being taken across organizations, and many companies are starting to ask why their identity stack is such an outsized drag on their margins. Keycloak presents a compelling case with its open-source nature. Unlike proprietary IAM solutions that come with hefty price tags and recurring subscription fees, Keycloak offers a cost-effective alternative without compromising on features or security.

By leveraging Keycloak, startups can significantly reduce their operational expenses, channeling those resources into core business activities such as product development and market expansion. Moreover, the open-source community surrounding Keycloak ensures continuous improvement and innovation, all without the burden of additional licensing costs.

Overview​

A multi-tenant application is a software architecture where a single instance of an application serves multiple, distinct customer groups or “tenants.” Each tenant, often representing an organization or user group, shares the same underlying infrastructure and codebase but operates within its own securely isolated environment. This allows each tenant to have individualized data, configurations, and sometimes even unique customizations, while benefiting from a shared platform that reduces overall resource demands and maintenance. Multi-tenancy is commonly used in SaaS (Software as a Service) applications, enabling businesses to scale efficiently, lower costs, and streamline updates while ensuring that each tenant’s data and settings remain private and distinct from others within the same application. This approach is particularly valuable in enterprise applications, where companies may need to provide access to different organizations, departments, or customer groups within a single solution.