Self-hosted or managed — the alternative to WorkOS & Okta

Your Identity Infrastructure. Your Control.

RealmSSO is a control plane for Enterprise Identity & SSO — and for the AI agents acting on your customers’ behalf. Standard identity protocols: SAML, OIDC and SCIM, with scoped agent credentials for fine-grained MCP tooling passed to your internal products, tools, and services. Run it yourself or let us host it, without vendor lock-in.

Get Started Deployment Guide

No vendor lock-in. No per-seat pricing. No per-connection fees.

What RealmSSO does — and where it is going

Three things that ship today, three things it is becoming. Every slide links to the page that carries the full claim and its caveats.

Today · 1 of 6

Shipped

Your customers sign in with the identity provider they already run.

Entra ID, Okta, ADFS, Google, or any SAML or OIDC provider. RealmSSO gives each customer their own realm, brokers the sign-in, and hands your application one OIDC identity. You build the integration once.

Metadata upload or manual entry, automatic identity-provider creation, health checks per connection.

SAML 2.0 →OpenID Connect →

The customer keeps their IdP; you keep one integration. The realm in the middle is what makes the second customer free.

Today · 2 of 6

Shipped

Hand the setup to their IT admin — with a link, not a ticket.

You create the account and send one portal link. Their administrator opens a branded Admin Portal, pastes three URLs into their Entra or Okta, and tests a login. No shared screen, no back-and-forth over certificates.

Magic-link access, connection testing, status the admin can read without calling you.

Customer Admin Portal →

Three hops, one of them theirs. The portal is branded as yours and scoped to their account only.

Today · 3 of 6

Shipped

See every connection, every login, every change — in one place.

Connection health, login events, SCIM activity and a full audit trail, for all your customers, from one dashboard. When a customer says "SSO is broken", you already know which certificate expired.

Health checks and certificate expiry per connection; audit events carry who, what and when.

Observability →SCIM Directory Sync →

Example rows, not live data. The point is the third one: you see the expiring certificate before the customer sees a failed login.

Where it is going · 4 of 6

Shipped server-side — API-first

One identity layer between all your products and all your customers' companies.

Register a product once. Grant it to a customer, and RealmSSO provisions that product a client inside the customer's realm — SAML or OIDC — so the product keeps the identity system it already trusts while the customer keeps their IdP, their MFA and their offboarding. No grant, no access.

Registrations, grants, provisioning and the per-customer handout run over the API today; there is no configuration screen yet, and no login has been driven through either onboarding leg. A pilot on one real customer realm is what closes it.

Identity Gateway →

The federation is the set of lines. Each solid line is a grant RealmSSO turned into a real client in that company's realm; the dashed one is a product never granted to Company A, which therefore cannot reach it.

Where it is going · 5 of 6

Designed and ratifiedEstimated Q4 2026 · October to December

Keep signed-in users working when their identity provider cannot be reached.

Ships, plants, clinics and field sites lose the network. In the design, a user who already signed in on a device would keep working on a token sealed into that device, released only behind the device's own unlock, for a window the customer sets. No device lock, no offline. Never a fresh login while the IdP is unreachable.

Ratified in ADR 0010; the server half is in review, the device SDK is not built. The window is the customer's offboarding latency, chosen by them — there is no platform default and no ceiling.

Offline Operation →

Continuity, not sign-in. The sealed token was minted while the IdP could vouch for the user; the unlock is a local gate that never reaches a server; the bar is the customer's decision.

Where it is going · 6 of 6

Agent identity shipped — API-firstMCP proposed — ADR 0017, not built

Agents and MCP clients, governed like people — on the way in and on the way out.

In the design, an agent reaching one of your applications or MCP servers signs in through the customer's realm and receives a token for that one resource, never a pass-through. An agent working for you would reach third parties through a broker that holds the credential and enforces which destination, which scope, how much — so a steered agent can misuse a grant but can never leak a key.

OAuth 2.1 resource-server semantics, RFC 9728 discovery, PKCE, audience-bound tokens; a new agent audit actor; default-off per customer. What exists today: a per-connection agent grant, off by default at the connection and the account, and per-account agent clients, gated by API authorization rather than by that switch. The egress broker exists nowhere yet.

Agent & MCP Identity →Architecture →

Two boundaries, one policy point. The accent marks the hop that carries the decision: the audience-bound token on the way in, the broker that keeps the credential on the way out.

Slide 1 of 6

Built for B2B SaaS companies that need enterprise SSO

SAML 2.0OpenID ConnectSCIM 2.0Kubernetes NativeKeycloak Powered

Everything you need for enterprise SSO

A complete control plane for B2B identity that your customers will love and your team can trust.

SAML 2.0

Full SAML 2.0 support with metadata upload, manual configuration, automatic Keycloak IdP creation, and health checks.

OpenID Connect

OIDC discovery-based configuration with automatic client setup, secret encryption, and comprehensive redirect URI management.

SCIM 2.0 Directory Sync

SCIM 2.0 Users & Groups endpoints with standard schemas and bearer-token auth. Directory writes provision users and groups into Keycloak. Deprovisioning and group sync both ship off by default.

Customer Admin Portal

Branded, embeddable portal for your customers to configure their own SSO. Magic-link access, connection testing, and status monitoring.

Observability & Analytics

Connection-health results, SCIM event activity, an event feed, and a full audit trail — all in one dashboard.

Identity Gateway

Let customers sign in with their own IdP while each application keeps the identity system it already trusts — including one behind existing on-premises federation. Register a product once and grant it per customer; RealmSSO provisions it into each granted realm, default deny. API-first: the control plane ships over the API, with no configuration UI yet.

Offline Operation

Designed: keeping an already-signed-in user working when their identity provider is unreachable, on a sealed token behind device unlock, for a window the customer sets. Ratified in ADR 0010 and not built; never a fresh login offline.

Agent & MCP Identity

Give each AI agent its own identity in your customer’s realm instead of a shared key: a per-agent client, claims your application can check, and two kill switches. API-first; the assertion grant is off by default, and the MCP half is designed in ADR 0017 and not built.

API & Webhooks

Everything is API-first. RESTful API with API key authentication and SSRF-guarded webhook endpoints you configure from the dashboard.

How it works

Deploy once. Manage all your customers' SSO from one place.

Runs where you choose

Your Kubernetes cluster, your Keycloak or the bundled one, your network boundary — one Helm chart, and every identity record stays on infrastructure you operate. Or we run the same thing on our cluster, in one realm for your account.

Their admin sets it up

Create the account and send one Admin Portal link. The customer's IT administrator configures their own SAML, OIDC or SCIM settings and tests a login — no ticket, no shared screen.

You see everything

Every connection, login event, directory sync and configuration change, for all your customers, in one dashboard with a full audit trail.

Your cluster or ours. Your data either way.

Run RealmSSO on infrastructure you own: your own Kubernetes cluster, your Keycloak instance, every identity record inside your own network boundary. Or let us host it on the cluster we already operate — one Keycloak realm for your account, deployed and upgraded by us. No per-connection pricing on either path.

Start Deploying Compare the tiers