For B2B software companies whose customers ask for single sign-on
Identity and trust for B2B software.
Your customers sign in with the identity provider they already use. We run it for you.
RealmSSO is a control plane for Enterprise Identity & SSO, and for the AI agents acting on your customers’ behalf. It uses standard protocols (SAML, OIDC and SCIM), with the limits stated on each feature page.
PricingA conversation, not a price list. No per-seat pricing. No per-connection fees.
For AI agents, too. Each agent can get its own identity in your customer’s realm, not a shared key. Building now: scopes for each agent, and brokered calls to third-party MCP servers.
Each customer gets a separate realm, with its own users and signing keys. Start with one application; the same realm can serve more than one. Underneath, the servers, the databases and one key ring are shared: today, one machine with no standby.
You send an invite link that works once and lasts 30 minutes. Your customer’s IT admin sets up SAML in the Admin Portal and can turn on SCIM. You set up OIDC in the dashboard or the API.
Customer SSO, a portal for their IT admin, observability, the Identity Gateway, identity for AI agents, and offline operation. Each one links to the page with its details and its limits.
Live now
Live now and Building now
Building now
Live now
Your customers sign in with the identity provider they already use.
RealmSSO speaks standard SAML 2.0 and OpenID Connect, so each customer connects the identity provider (IdP) it already uses. Not yet tested against Entra ID, Okta, ADFS or Google. Each customer gets its own account and its own realm: a separate sign-in space with its own issuer. Your application must check the issuer and the audience.
A SAML connection takes a metadata URL, pasted metadata XML (API only) or manual entry. An OIDC connection takes a discovery URL. RealmSSO creates the identity provider configuration automatically, and a check runs on demand. Encrypted SAML assertions are not supported yet.
Each customer keeps its own identity provider. Each realm is its own issuer, so your application holds one configuration for each realm.
Live now
Hand SAML setup to their IT admin with a link, not a ticket.
You send your customer's IT admin an invite link. It works once and lasts 30 minutes. The IT admin needs no password and gets no access to your dashboard. In the Admin Portal they enter their identity provider's metadata URL or three manual values, and save. The portal then shows three values to paste into their identity provider: the ACS URL, the SP entity ID and the audience URI. They can also turn on SCIM and set its token.
For setup, the portal covers SAML and the SCIM switch. It has no metadata upload, no connection test and no working OIDC tab, so you set up OIDC in the dashboard or the API. A later save that changes the IdP's entity ID replaces the connection's identity provider configuration and drops every user's link to it, so returning users cannot complete sign-in through it. A save that keeps the entity ID, a new certificate included, keeps the links.
enter metadata URL or 3 manual values · save · paste the 3 values shown
You send the link and their IT admin does the rest of the SAML setup. The portal shows the logo and accent colour you set on the account through the API, and covers that account only.
Live now
See each account's connection health, sign-in events and changes.
Connection health is checked on demand, not on a schedule. A check flags a certificate that has expired or expires within 30 days, and no alert is sent. Sign-in events arrive about once a minute and are kept 90 days by default. The audit log records changes made through the API.
The dashboard shows one account at a time: sign-in and SCIM counts, a health summary and the 50 latest events. The audit log records who, what, when and from where, best effort. Dashboard, portal and user sign-ins are not in it. There is no metrics endpoint.
healthConnection B · SAMLchecked: cert expires in 9 dayshealthy
auditConnection A · SAMLconnection edited by API keylogged
Example rows, not live data. A health check records healthy or down, and a certificate that expires within 30 days is flagged when the connection is checked.
Live nowPlatform operator only
Register a product once. Grant it to each customer account.
A product is an application in a catalogue that a platform operator keeps. The platform operator, who is RealmSSO staff, registers a product once. A product grant names one customer account. Provisioning it gives that account a SAML or OIDC client for the product, in the account's own realm. A product's client exists only in the realms of accounts that hold a product grant. Revoking a product grant removes the client at once.
Registration, product grants, provisioning and the handout of per-customer values run through the API and a board that only a platform operator can use. No login has yet been carried end to end through the gateway. Signed requests from products: Building now. A SAML pilot needs them first.
Each solid line is a product grant that became a client in that company's realm. The dashed line is a product never granted to Company A, so it has no client in Company A's realm.
Live nowBuilding now
Each agent can get its own identity in your customer's realm.
Live now: an agent can have its own client in your customer's realm. It uses a secret shown once, or no stored secret when its platform has a public token issuer, such as managed Kubernetes or GitHub Actions. Its tokens carry attribution claims that say who acted, not what the agent may do. Revoking the client disables it, and tokens it already holds run to their expiry. Building now: an account admin would grant scopes to each agent, and your server must still check each scope. An egress broker would call third-party MCP servers for an agent that never holds their keys.
The assertion grant, which lets a customer's identity provider vouch for an agent, is off by default for the account and for each connection. The configuration route returns a discovery template for your own MCP server to fill in, and it adds no scope. Secretless registration was tested against a stand-in for public token issuers, not against managed Kubernetes or GitHub Actions themselves.
client secret, or a platform-issued token (no secret stored)
sign in
Customer's realm
an identity per agent · four attribution claims · revoke · audit
token
Your app / MCP server
can log who acted · discovery template from the config route
Building now: lanes 2 and 3, the designs for scopes and egress
2 · Scopes granted to agentsBuilding now
Your resource
you would name its scopes; a platform operator would register them
scopes
Account admin would grant
scopes to one agent; the realm is designed to refuse to mint the rest
token
Your server
must still check each scope
3 · Egress to third partiesBuilding now
Your agent
would hold no third-party key
call via
RealmSSO egress broker
an egress grant would name a destination and its tools; default deny; every decision would be audited
with key
Third-party MCP / API
would be called by the broker, using the key the broker holds
a direct call: RealmSSO never sees it
Solid boxes are Live now. Dashed boxes show a design, marked Building now. A call an agent makes directly to a third party never reaches RealmSSO.
Building now
A signed-in user would keep 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. Only the device's own unlock would release it, and only for a window the customer sets. Without a device lock there would be no offline use. A fresh login would never be possible while the identity provider is unreachable.
The device half is not released yet. The server half is Live now · API only: a per-connection offline policy set through the API, which no device enforces. The customer sets the window, and a window longer than the realm allows is refused. A user disabled at the identity provider would keep working at least until the window ends.
The window is the shortest offboarding delay the customer accepts: someone disabled at their IdP would keep working at least until it elapses.
Continuity, not sign-in. The sealed token would be issued while the identity provider could vouch for the user. The unlock would be a local gate that never reaches a server. The window is the customer's decision.
1 / 6 · Customer SSO
The exact status of each capability, and what we do not have yet, is on What ships today.
How it works
We run it. Their IT admin sets it up. You watch it.
1
We run it
You install and run nothing. We deploy and upgrade one shared instance, with a realm (a separate sign-in space) for each of your customers’ accounts. Accounts are isolated between realms. The machine, databases and keys below the realm are shared, and today that is one machine with no standby.
2
Their IT admin sets up SAML
You send an invite link that works once and lasts 30 minutes. Your customer’s IT admin sets up SAML in the Admin Portal and can turn on SCIM. You set up OIDC in the dashboard or the API.
3
You watch it
Check a connection’s status and health on demand. Sign-in events arrive about once a minute and are kept 90 days by default. The audit log records changes made through the API. No alert is sent for an expiring certificate or a failed webhook.
We run it. Your customers keep their own identity providers.
RealmSSO is a managed service. We deploy and upgrade one shared instance, with a realm for each of your customers’ accounts. Your customers keep signing in with the identity provider they already use. No per-seat pricing. No per-connection fees.