Security

Each customer account gets its own realm: a separate sign-in space with its own users, clients, identity-provider links and signing keys. Tokens, sessions and identity-provider links do not cross between realms. Your application must check the issuer and the audience of each token.

Below the realm, all accounts share one RealmSSO server, one sign-in service, both databases, one key ring and one machine. Isolation is logical.

The product stores the email address each dashboard user signs in with; each account's name, identifier and registered email domains; each SSO connection's configuration; the IT admins you invite; a hash of each API key; webhook destinations and delivery logs; audit rows and sign-in events; and the users and groups a customer's directory pushes over SCIM. In each customer's realm, the sign-in service keeps a user record with the name and email address of each person who signs in, and for an OIDC connection the tokens their identity provider issued.

We do not use any of it for advertising, we do not sell it, and we do not send marketing email. The product data sits on the instance described in How we run your instance.

Exactly two database fields are encrypted, with AES-256-GCM: a connection's OIDC client secret and its SAML signing certificate. API keys, SCIM tokens, dashboard sign-in links, refresh tokens and Admin Portal invite tokens are stored only as SHA-256 hashes. Webhook signing secrets are stored readable, because the server needs them to sign each delivery.

The encryption keys sit in one key ring, which serves all accounts. There is no KMS, no HSM and no customer-managed key. The ring supports rotation. No rotation has run in production.

An account has three roles: viewer, member and account admin. An API key belongs to one account, and RealmSSO checks its scopes on each route that accepts a key. By default a key has the scope * and no expiry.

Your customer's IT admin needs no account: an invite link opens one session on one account, works once, and ends 30 minutes after RealmSSO makes it. A platform operator is RealmSSO staff, and can read across accounts. A database row marks the role, and it is set outside the API. No API key can hold the role.

Each account has an audit log of changes made through the RealmSSO API: who acted, the action, the resource, the IP address, a severity and a time. Writes are best effort, and the log has no export. Every member of the account can read it. Sign-ins by your customers' users, SCIM syncs and Admin Portal sign-ins are recorded as events, kept 90 days by default.

Each webhook delivery carries an HMAC-SHA256 signature over the timestamp, the delivery, the event and the raw body, keyed with the webhook's secret. Your endpoint must recompute it and reject a delivery that does not match. RealmSSO checks that a webhook's URL points to a public address when you create or update it.

Your customers connect with SAML 2.0 or OpenID Connect, and their directories with SCIM 2.0. Your application speaks standard OIDC to the sign-in service. Each SAML assertion must be signed, and its signature is verified against the identity provider's signing certificate; RealmSSO refuses metadata that holds no signing certificate.

Each agent can get its own client in your customer's realm, not a shared key. Revoking a client disables it, so it can get no new token; tokens it already holds run to their expiry. The account's agent-access switch covers agent clients: while it is off, no agent client can be registered, and turning it off disables the existing ones.

Building now: scopes for each agent, and brokered calls to third-party MCP servers.