Skycloak Shorter Path: Managed Upstream Keycloak for Azure AD B2C Teams

Last updated: September 2026

TL;DR

The usual blocker on the Keycloak path out of Azure AD B2C is not Keycloak. It is the cluster, the database, the upgrades, and the on-call rotation that a small team cannot staff. Managed upstream Keycloak removes that layer without reintroducing the thing you were escaping: the configuration stays exportable realm JSON, and there is no per-monthly-active-user bill.

What “shorter path” actually means here:

• Upstream, not a fork. Standard Keycloak 26.x. Your realm export works anywhere Keycloak runs, including on your own infrastructure later.
• No per-MAU line item. The pricing problem that pushes consumer-facing tenants off B2C does not follow you.
• Day one is a working realm, not a Helm chart. You start mapping flows immediately instead of spending the first sprint on infrastructure.
• Workforce federation is a recipe, not a project. Brokering Microsoft Entra ID for employee access is a guided wizard.
• This is not the Microsoft-supported path. Entra External ID is. Pick Keycloak for portability and cost, with clear eyes.

If you have not settled the destination question yet, start with Part 2, Azure AD B2C vs Entra External ID vs Keycloak. For the technical steps of the migration itself, the canonical guide is Migrating From Azure AD B2C to Keycloak.

Start with the honest framing

Microsoft Entra External ID is the Microsoft-supported successor to Azure AD B2C. Microsoft publishes migration planning guidance for it, actively develops it, and supports it under a commercial agreement. If your organization is standardized on Azure and wants a vendor-backed destination, that is the right answer and no amount of vendor blogging should talk you out of it.

Managed Keycloak is for a different team. Specifically, for teams who looked at the successor and concluded that two of the things they disliked about B2C follow them across:

1. Per-monthly-active-user pricing. A CIAM platform bills you for consumers, not employees. Free-tier users, trial accounts, and returning dormant users all count. For products where revenue per user is low and user count is high, MAU pricing scales against the business rather than with it.
2. Configuration you cannot take with you. Your identity setup stays a vendor-hosted artifact. When lock-in is the actual concern, moving between hosted products does not resolve it.

Keycloak addresses both. It has no per-user license, and a realm exports to JSON you can diff, commit, and re-import elsewhere. The cost is that Keycloak is software someone has to run, which is exactly the gap a managed provider fills.

The operational gap, priced honestly

Teams evaluating self-hosted Keycloak tend to price the license (zero) and skip the rest. Here is what “the rest” consists of.

None of that is exotic for a platform team that already operates stateful services. All of it is a serious commitment for a product team of five. Identity is also the worst service to learn operations on, because when it is down, everything is down.

The decision is not “open source versus SaaS.” It is “who runs the thing,” and there are three honest answers: your platform team, a managed provider, or nobody (which is what self-hosting without capacity really means).

What the shorter path looks like in practice

Here is where the time actually goes on a B2C exit, and which parts managed hosting removes.

The mapping work does not disappear and nobody should claim it does. Inventory, flow mapping, and the IEF rebuild are the same on either row, and they are the bulk of the project. What changes is that you start on day one rather than after an infrastructure sprint, and you are not simultaneously learning to operate Keycloak while running a customer-facing cutover.

That second point matters more than it sounds. Dual-run puts your new IdP in the critical path of every customer login while the old one is still live. Doing that on infrastructure your team stood up three weeks ago is a compounding risk.

Getting started

1. Provision a realm

Sign up and create a Keycloak instance. You get an admin console at a Keycloak URL and a standard OIDC discovery endpoint:

https://{your-realm}.skycloak.io/realms/{realm}/.well-known/openid-configuration

That is the URL your applications will eventually point at, replacing the B2C policy-specific form:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1A_signup_signin

Note the structural difference, because it drives application work: B2C encodes the policy in the URL, Keycloak has one discovery endpoint per realm. Applications that build per-policy authority URLs need code changes rather than config changes. Find them during inventory.

2. Recreate your user profile schema

Every B2C extension attribute (extension_{appId}_{name}) becomes a Keycloak user profile attribute under Realm Settings > User Profile. Drop the prefix, keep a mapping table so your import script knows which source field feeds which target.

Keycloak’s declarative user profile handles display names, required flags, permissions, and validators, which covers most of what B2C input claim configuration expressed.

3. Build your authentication flows

Under Authentication > Flows, recreate each B2C user journey. Built-in user flows map cleanly. Identity Experience Framework custom policies are the real work, and the full mapping (technical profiles, claims transformations, preconditions, validation profiles calling REST) is in Azure AD B2C Custom Policies (IEF) to Keycloak Flows.

4. Reconnect your identity providers

Every B2C claims provider becomes a Keycloak identity provider. Social providers (Google, Facebook, GitHub, Apple) are built in. Enterprise providers use OpenID Connect v1.0 or SAML v2.0 with metadata import.

Full configuration reference: Skycloak identity providers documentation.

5. Import users and deploy the password bridge

Import users without credentials, storing the B2C object ID as an attribute for cross-referencing. Then deploy your lazy-migration authenticator, because B2C does not export password hashes and never will. The full cutover plan is Part 4: Dual-Run Cutover from Azure AD B2C.

Federating Microsoft Entra ID for workforce access

Most teams leaving B2C are not leaving Microsoft. Your customers move to Keycloak; your employees still sign in with Entra ID, and your internal admin tools still need to respect that.

That is brokering, and it is one of the things Keycloak is genuinely good at. Keycloak becomes the hub your applications trust, with Entra ID federated upstream for workforce users and local or social accounts for customers. Applications integrate once.

Using the Azure AD SSO recipe

Skycloak ships a guided recipe for this specific integration:

1. Log into your Skycloak account.
2. Open Recipes in the left sidebar.
3. Select Azure AD SSO Integration.
4. Click Start Recipe.
5. Follow the wizard, which walks through the Azure app registration, redirect URIs, client ID and secret, attribute mappers for email, first name and last name, and a test login.

The recipe handles OIDC discovery, attribute mapping, and trust settings, which is the part people usually get wrong by hand.

For manual configuration, self-hosted Keycloak, or SAML instead of OIDC, see the enterprise SSO setup guide and How to Set Entra ID SAML in Keycloak as an IdP. For the architectural case for hub-and-spoke federation generally, see Federated SSO vs a Single IdP.

Routing customers and employees differently

With both populations in one realm, route by email domain using kc_idp_hint so employees skip the customer login page and go straight to Entra ID:

https://{your-realm}.skycloak.io/realms/{realm}/protocol/openid-connect/auth
  ?client_id=admin-portal
  &redirect_uri=https://admin.example.com/callback
  &response_type=code
  &scope=openid
  &kc_idp_hint=entra-id

Details in Use kc_idp_hint to Choose Identity Provider in Keycloak. For per-customer B2B federation where each enterprise brings its own IdP, Keycloak Organizations handle domain routing by linking realm-level identity providers to each Organization. A dedicated per-organization IdP dashboard is not shipped yet (tracked in GitHub issue #1355); the supported pattern today is realm-level IdPs with descriptive aliases, then linked to Organizations. See Multitenancy in Keycloak Using the Organizations Feature.

Why upstream matters more than it sounds

“Upstream Keycloak” is not marketing filler in this context. It is the specific property that makes managed hosting compatible with the reason you are leaving B2C.

A forked or heavily modified Keycloak reintroduces the problem. If the provider has added proprietary constructs your realm depends on, your configuration is no longer portable, and you have swapped one lock-in for another with extra steps.

Upstream means:

• Standard Keycloak 26.x, tracking the upstream release line.
• Realm JSON export and import that works against any Keycloak, including one you run yourself.
• The standard SPI model, so your custom authenticators, protocol mappers, and event listeners are ordinary Keycloak providers.
• Standard endpoints and standard admin API, so tooling, Terraform providers, and scripts written against Keycloak work unchanged.

The practical test to apply to any managed Keycloak vendor: export the realm, read the JSON, and ask whether you could import it into a vanilla Keycloak container. If yes, the exit door is real. If no, keep looking.

Frequently asked questions

Is managed Keycloak the same as Azure AD B2C with a different logo?

No, and the difference is structural rather than cosmetic. Azure AD B2C bills per monthly active user and stores your configuration as a vendor-hosted artifact including proprietary IEF XML. Managed upstream Keycloak has no per-user license, and the configuration is standard realm JSON you can export and run elsewhere. You are buying operations, not the platform.

Should I use Entra External ID instead?

If your organization is standardized on Azure, procures through Microsoft, and wants a vendor-supported destination with a support contract, yes. Entra External ID is the Microsoft-supported successor to Azure AD B2C. Choose Keycloak when per-MAU pricing works against your business model or when configuration portability is a genuine requirement. Part 2 has the full comparison.

Can I move off managed Keycloak later?

Yes, and that is the point of upstream. Export your realm to JSON and import it into a Keycloak you run yourself or with another provider. You will still need to handle the user credential store and any custom provider JARs, but the configuration layer moves cleanly. A managed Keycloak that cannot do this is not solving the lock-in problem.

Does managed Keycloak support custom authenticators?

Yes, with a plan caveat. Custom provider JARs (Authenticator SPIs, protocol mappers, event listeners) are ordinary Keycloak extensions. On Skycloak, uploading your own JAR is an Enterprise Custom Extensions capability; the curated extension marketplace is available on all plans. That matters for a B2C migration because the lazy-migration password bridge is typically a custom authenticator. See Dual-Run Cutover from Azure AD B2C and the Extensions docs.

How much of the migration does managed hosting actually remove?

The infrastructure and operations layer, which is real but is not the bulk of the project. Inventory, flow mapping, custom authenticators, user import, and the cutover are the same work regardless of who hosts. What you gain is starting on day one instead of after an infrastructure sprint, and not running a customer-facing cutover on a cluster your team just learned to operate.

Can I keep using Microsoft Entra ID for employees?

Yes, and most teams do. Keycloak brokers Entra ID as an upstream identity provider for workforce users while customer identities live locally or federate through social providers. The Azure AD SSO recipe configures this, and the identity providers documentation covers the details.

Where to go next

The shortest honest summary of this series: Azure AD B2C is not shutting off tomorrow, Entra External ID is the Microsoft-supported destination, and Keycloak is the path for teams who want exportable configuration and no per-MAU bill. Managed hosting exists to make the third option available to teams who do not want to run a cluster to get it.

If you want to see what your realm looks like before deciding anything, Skycloak offers a 7-day free trial with no credit card. Build a flow, import a handful of test users, export the realm JSON, and read it. That last step is the one that tells you whether the portability claim holds up, and it is worth doing on every vendor you evaluate, including this one.

Azure AD B2C exit series

This post is Part 5 of a five-part series on leaving Azure AD B2C.

1. Azure AD B2C End of Sale and Support Timeline (What Microsoft Actually Said)
2. Azure AD B2C vs Entra External ID vs Keycloak: Three Exit Paths
3. Azure AD B2C Custom Policies (IEF) to Keycloak Flows: Mapping Guide
4. Dual-Run Cutover from Azure AD B2C: Passwords, Apps, and Rollback
5. Skycloak Shorter Path: Managed Upstream Keycloak for Azure AD B2C Teams (this post)

For the step-by-step technical walkthrough, see Migrating From Azure AD B2C to Keycloak.