Security overview

The decision: you let RealmSSO's sign-in service sit between your application and each customer's identity provider. RealmSSO runs it for you.

The risk: all accounts share one RealmSSO server, one sign-in service and one machine. RealmSSO gives each account its own realm, a separate sign-in space. Between realms, tokens and sessions do not cross. Below the realm, everything is shared. RealmSSO has no production customers yet and holds no certification.

Isolation between customers

RealmSSO creates a realm for each account, in the same request that creates the account. A realm has its own users, clients, identity-provider links and signing keys.

Between realms, tokens, sessions and identity-provider links do not cross. The sign-in service does not accept one account's token for another account. We ran the attacks on a test deployment. Accounts and isolation lists them.

The token's issuer identifies the account. Your application must check the issuer and the audience of each token.

One account for each realm is the design. Nothing in the database forces it. A scan at start-up and every five minutes records any realm that holds two accounts. The scan finds a breach after the fact.

Inside a realm, the server checks that an account owns an object before it reads or changes it. This check is application code. The database does not force it.

What is encrypted and what is hashed

Exactly two database fields are encrypted, with AES-256-GCM. They are a connection's OIDC client secret and its SAML signing certificate.

RealmSSO stores only a SHA-256 hash of these credentials. They are API keys, SCIM tokens, dashboard sign-in links, refresh tokens and Admin Portal invite tokens.

RealmSSO's database holds no secret for your application's sign-in client, no product client secret and no agent client secret. The sign-in service holds them, and RealmSSO keeps no copy. This site makes no claim about how the sign-in service stores them.

The encryption keys sit in one key ring in the platform's secret store. One ring serves all accounts. There is no KMS, no HSM and no customer-managed key. The ring supports rotation. No rotation has run in production.

This site makes no claim about disk encryption, backup encryption or encryption of the database connection. See Encryption and secrets for each stored credential.

Who can do what

An account has three roles. From lowest to highest, they are viewer, member and account admin. RealmSSO reads the role from the database on each request.

Only an account admin can set the connection-error policy and manage API keys. A member can do every other write. That includes deleting the account and inviting an IT admin. No route adds a member, removes one or changes a role.

An API key belongs to one account. 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. The link works once, and the session ends 30 minutes after RealmSSO makes the link. Whoever holds the link acts as the IT admin.

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.

Access control has the full list.

What is recorded

Each account has an audit log. A row records who acted, the action, the resource, the IP address, a severity and a time. The log covers changes made through the RealmSSO API.

Writes are best effort. An action can succeed with no audit row. The log is a plain database table. Nothing detects a later change to a row.

Every member of the account, from viewer up, can read the log. It has no export and no streaming. RealmSSO keeps the rows while the account exists and deletes them with the account.

User sign-ins, SCIM syncs and Admin Portal sign-ins are not in the audit log. They are events. Events carry an email address and an IP address. RealmSSO keeps events 90 days by default, then purges them. Dashboard sign-ins are not in the audit log, and they are not events. See Audit log.

API hardening

Every API response carries standard security headers and a one-year HSTS header. We captured the headers from production on 2026-10-03.

The API limits each client address to 200 requests per window. It counts requests in the server's memory. We measured the limit of 200 on production on 2026-10-03. The server trusts one proxy hop, so a forged X-Forwarded-For header does not choose a caller's rate-limit bucket.

Sessions

A dashboard session is a 24-hour token. The server sets it in an httpOnly cookie. The sign-in response also returns it.

A 30-day refresh token comes with the session. Each use of the refresh token gives a new one. If someone presents a used refresh token again, RealmSSO revokes all refresh tokens of that user.

Dashboard sign-in

Dashboard users sign in with an email link. There is no password. The link works once and lasts 15 minutes.

Dashboard sign-in does not depend on the sign-in service. It works while the sign-in service is down.

What we do not claim

• We hold no SOC 2, ISO 27001 or other certification, and no third-party penetration test. An internal security review exists.
• RealmSSO has no production customers yet. No customer account has gone live on production.
• There is no dedicated instance, no private connectivity, no customer-managed keys and no choice of region.
• The internal security review of the server code is dated 2026-07-30. It recorded findings by file and line. We have not published it.

What ships today has the list of what we do not have yet.

If you leave

Your application speaks standard OIDC to the sign-in service. The addresses that your customers registered in their own identity provider point at RealmSSO. For a SAML connection, these are the ACS URL and the entity ID. For an OIDC connection, the address is the redirect URI.

Moving to another service is therefore a coordinated change for each customer. Each customer must register new addresses in their identity provider.

No procedure for exporting your data is documented yet. Deleting an account deletes its realm. See Backup, recovery and deletion.