GR Patil

We're shipping experimental SCIM 2.0 provisioning for the Phase Two Organizations extension. Each organization in a realm can now act as its own SCIM 2.0 service provider, so an upstream IdP like Okta or Entra ID can push users into a specific tenant rather than into the realm as a whole.

This is the piece of the multi-tenant story that Keycloak's stock SCIM support doesn't address today, and it's been a heavily requested item from customers running Organizations in production.

If you are exposing tools over MCP, you usually do not want every client on the network calling them anonymously. Even for a local prototype, you typically want a real login flow, consent, scoped access tokens, and a clean way to validate who is allowed to run what.

Keycloak is the easiest way to do that without inventing your own authorization layer. It already handles browser login, consent, token issuance, JWKS discovery, and OAuth metadata. Your MCP server just needs to behave like a protected resource and validate bearer tokens correctly.

In this guide, we will build a tiny calculator MCP server in Python, protect it with Keycloak, and connect to it from VS Code using Dynamic Client Registration (DCR). By the end, VS Code will open a browser to Keycloak, you will sign in, approve access to the mcp:run scope, and then call your MCP tools directly from chat.

Phase Two has recently launched Auth.it, a modern authentication platform built for developers who want the power of Keycloak with the simplicity, polish, and developer experience of modern identity providers like WorkOS, Stytch, and Clerk — all at a fraction of the cost.

Last Friday, Niko Köbler (aka "Mr. Keycloak"), invited us to demonstrate Auth.it and explain how we built it on his livestream, Keycloak Friday Chat. If you're interested in an overview of the new platform, and would like to know the details of how it was implemented as a set of Keycloak extensions, please watch the recording of the livestream.

Part 3: Customizability for Tailored Solutions: Why Keycloak Stands Out​

One size rarely fits all, especially in the world of enterprise software. Startups require flexibility to adapt and tailor IAM solutions to their unique business requirements. Keycloak shines in this aspect, offering extensive customization capabilities that empower startups to mold the platform according to their specific needs.

From branding and user interface customization to advanced authentication flows and authorization policies, Keycloak provides a comprehensive toolkit for startups to craft seamless and secure user experiences. Whether integrating with existing systems or building entirely new functionalities, Keycloak's flexibility ensures a perfect fit for any enterprise SaaS startup. Here’s how Keycloak’s flexibility stands apart from commercial, closed-source solutions, and why this is a key differentiator:

Part 2 - Owning Your Data: Security, Privacy, and Control​

In the age of data breaches and privacy concerns, owning and controlling your user data is not just a preference but a strategic imperative for organizations, particularly when it comes to Identity and Access Management (IAM) solutions. Let's explore the reasons why owning your data matters and the risks associated with entrusting it to a Software-as-a-Service (SaaS) solution.

Part 1: Standardized Protocols and Minimal Feature Set Differentiation​

In the realm of Identity and Access Management (IAM) solutions, it's essential to recognize that many offerings, both commercial and open source, operate on standardized protocols such as OpenID Connect (OIDC), Security Assertion Markup Language (SAML), System for Cross-domain Identity Management (SCIM), Lightweight Directory Access Protocol (LDAP), and more. This adherence to standardized protocols often results in minimal differentiation at the feature set level across various options. Let's delve into this further:

In the ever-evolving landscape of Enterprise SaaS, navigating the complexities of identity and access management (IAM) can be a daunting task. As a startup striving for excellence in user experience and security, choosing the right IAM solution is paramount. Enter Keycloak, a powerful open-source IAM tool that not only meets but exceeds the demands of modern startups.

We recently gave a talk at the Keyconf24 conference in Vienna on how to extend Keycloak using its extensible SPI structure. In addition to showing what is possible and how to get started in building extensions, we also use our Events and Webhooks extension as a real-world example. The hosts of the conference have posted the video of the talk on Youtube.

We recently gave a talk at the Keycloak DevDay 2024 conference in Frankfurt on our Organizations extension which provides single Realm multi-tenancy to Keycloak for modern SaaS applications. The hosts of the conference have posted the video of the talk on Youtube.

With many companies racing into the cloud, very little is written about the huge opportunity, and potential pitfalls of building software for on-prem and private cloud deployments. With the growing Kubernetes and CNCF ecosystems, the balance point to justify self-hosting is constantly shifting. This is great news for companies that must host data and applications inside the enterprise. For software vendors looking to serve this exploding market, authentication can be a blind spot.

A story, inspired by customer use cases:​

You’ve built a successful enterprise SaaS product, and your cloud offering has taken off. Recently, you’ve been getting inquiries from government agencies, large companies in regulated industries, and foreign companies – all of which have legal, compliance or regulatory requirements that prohibit them from using your product in the cloud.

Given the size of the opportunity, you’ve decided to go for it. Your team has packaged your application up as a set of Kubernetes manifests, making changes, replacing cloud services with open source alternatives, and even built out a runbook to help your devops peers at the customer operate it themselves.

The big day comes, and you’re installing at your first customer. You expect that there will be some minor bumps along the way, but their first question just flattens you: “How do we connect this to our in-house identity provider?” It was a question that was never on your radar, but now it’s the most important thing for the customer.

Like most SaaS companies, you’re probably either hand-rolling your authentication and user management using something like Passport.js, Devise, Django, etc., using some social login options, or using a cloud-only service like Auth0 or WorkOS. If you had implemented SAML, the most common protocol for just-in-time user provisioning with enterprise identity providers, you probably went for a basic approach. You wrongly assumed that user management and identity brokering would be easier for on-prem.

You throw some engineering and customer success resources at the problem, but quickly realize it’s not a scalable solution. The customer wants to map their groups, and manage access and authorization through their IdP. Just the overhead of connecting to every possible type of IdP, and supporting that for every customer, will eat up your margin before they start using your application.