Realmdrop Core · Identity Platform
One login. Every product. Total control.
AuthRealm is the identity layer behind a growing family of live products. It gives your users one secure account across every site you build — and gives you a modern, scope-based permission system to decide exactly what each person can do.
The auth platform we built for ourselves, hardened in production, and now run everything on.
Why AuthRealm
A single AuthRealm identity spans all of your apps. Users sign in once and carry their account from one product to the next — no separate logins, no duplicate passwords, no re-registration. Each product sees only the roles and permissions that belong to it.
Short-lived access tokens, automatically rotating refresh tokens, server-side revocation, hashed passwords and tokens, rate-limited sign-in, and “log me out everywhere” in one call. The hard parts of auth are handled so your product doesn't have to.
AuthRealm uses scopes — small, named permissions like blogs:write or events:read. Bundle them into roles, hand roles to people, and every token carries exactly what its holder is allowed to do. Nobody gets more than they need.
Every product turns on only the features it uses — blogs, events, services, team, portfolio, testimonials, FAQs, RSVP-style flows, and more. One platform flexes to fit a wedding RSVP site and a storefront equally well.
Personal Access Tokens let a user mint a scoped credential for a bot, script, or integration — without ever sharing a password. Tokens can be named, scoped, rotated, and revoked at will.
Powering real products
A live, members-aware web product running on AuthRealm.
Guest sign-in and RSVP flows, secured end to end.
A boutique cattery site with managed content and access.
A plant-focused product with role-based content control.
Four very different products. One auth platform underneath all of them.
How people use it
The examples below show AuthRealm's current API. Version 2.0 introduces redirect-based single sign-on (OAuth 2.0 / OpenID Connect), where the password step moves to AuthRealm's own hosted login — see AuthRealm 2.0.
When a user signs in, AuthRealm returns a token tailored to one product context — who they are, what role they hold, and the precise scopes they're allowed.
POST /authRealm/login
Content-Type: application/json
{
"email": "guest@example.com",
"password": "SecurePassword123!"
}{
"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"refreshToken": "rotating-refresh-token",
"expiresIn": 900,
"roles": ["ContentEditor"],
"scope": "blogs:read blogs:write events:read"
}A single account can span multiple products — but every login is bound to one product at a time, and the token it issues is scoped to just that context. There's no accidental cross-over, and one product never learns which others a person belongs to. Sign in to a specific workspace, and get back a token scoped to exactly that product:
Choosing among your workspaces happens on AuthRealm itself — never by handing a product the list of the others. In 2.0, that selection moves into the hosted single sign-on screen.
{ "email": "guest@example.com", "password": "…", "tenantId": "plantaerium-workspace-id" }{ "accessToken": "eyJhbGc…", "tenantId": "plantaerium-workspace-id", "roles": ["TenantAdmin"] }Access tokens are short-lived by design. When one expires, the app silently exchanges the refresh token for a fresh pair — and the old refresh token is invalidated on the spot, so a stolen token can't be reused.
POST /authRealm/refresh
Content-Type: application/json
{ "refreshToken": "rotating-refresh-token" }Sign out of one session, or revoke every active session for the account in a single call.
POST /authRealm/logout
Content-Type: application/json
{ "refreshToken": "rotating-refresh-token", "all": true }Password reset always responds the same way, whether or not the email exists — so AuthRealm never reveals who has an account. Reset links are time-limited.
POST /authRealm/forgotPassword
Content-Type: application/json
{ "email": "guest@example.com" }{ "message": "If an account exists with this email, a password reset link has been sent" }What a product can see about its people
Any signed-in user can read their own profile at GET /v1/tenant/me.
Discover exactly what this product has enabled — and the scopes each feature unlocks.
List members, but only with the users:read scope. Permission is always enforced, never assumed.
GET /v1/tenant/features
Authorization: Bearer eyJhbGc...{
"features": [
{ "featureKey": "blogs", "isEnabled": true, "scopes": ["blogs:read", "blogs:write"] },
{ "featureKey": "events", "isEnabled": true, "scopes": ["events:read"] }
]
}Tokens for bots, scripts & integrations
A user can mint a Personal Access Token scoped to no more than they themselves can do — then use it like any other bearer token.
The plaintext token is shown once, then stored only as a hash — so it can never be read back, even by us.
Tokens are fully self-service: list them, rotate the secret if one leaks, or revoke instantly. A revoked token stops working on its very next request.
POST /v1/me/tokens
Authorization: Bearer eyJhbGc...
Content-Type: application/json
{
"name": "nightly-content-sync",
"scopes": ["blogs:read", "events:read"],
"expiresInDays": 90
}{
"name": "nightly-content-sync",
"token": "pat_9f8a7b6c5d4e3f2a1b0c...",
"scopes": ["blogs:read", "events:read"],
"expiresAt": "2026-09-06T00:00:00Z"
}Security, by default
Every refresh invalidates the old token — replay attacks have nothing to reuse.
Passwords and tokens are stored as hashes, never plaintext.
Login and password-reset responses never reveal whether an email exists.
Repeated attempts are throttled per source to blunt brute-force attacks.
Every protected call checks the caller's scopes — least privilege is the default.
A Personal Access Token can never grant more than its creator already holds.
Each access token represents exactly one product — no ambient cross-product authority.
Built on a clean, documented API
Every endpoint is described by an OpenAPI / Swagger specification, so the whole surface is explorable and importable into Postman, Insomnia, or your client of choice — interactive docs, generated clients, and instant try-it-out, straight from the spec.
{ "error": "invalid_credentials", "message": "Invalid email or password" }Where it's headed
AuthRealm 2.0AuthRealm today is our in-house identity platform: the engine we run our own products on, hardened by real production use across four very different sites.
Version 2.0 opens it up — turning AuthRealm from the system behind our products into a platform anyone can build on. A true, sellable identity service.
Redirect-based login using OAuth 2.0 and OpenID Connect — a user's password is only ever entered on AuthRealm itself, never seen by the products that rely on it. One trusted front door for every app.
Every product gets its own scoped keys, and a login is bound to the app that started it. A session or credential issued to one product can never reach another product's data — isolation is enforced by the platform, not by trust.
Register a new product, get your keys, and integrate in minutes — the same auth foundation we use, available to you.
Hosted docs, drop-in client libraries, and the same clean API and Swagger surface we ship today.
The foundation — multi-product identity, scoped permissions, rotating tokens, automation-ready PATs — is already here and proven. 2.0 is about putting it in your hands.
AuthRealm is the secure, scope-based identity platform that powers our products today — and, with 2.0, becomes one you can build on too.