Identity, passwordless

One key, every door.

Latchkey is an OpenID Connect provider without passwords: magic links, phone codes and passkeys, with tenants, teams and roles that speak your product's language.

Open the console Read the quickstart

sign-in — a Go backend

$ curl -s https://auth.latchkey.id/.well-known/openid-configuration | jq .issuer"https://auth.latchkey.id"$ latchkey -bootstrap you@example.comidentity ensured · org latchkey claimed · latchkey:owner granted$ go test ./...ok  latchkey/e2e  12.4s

Behind

tripline
runsheet
wardroom
purser
foghorn

What you get

The whole door, not just the lock.

Everything a product needs to sign people in and know who they are — and nothing it has to build itself.

Passwordless

Magic links, email and phone codes, passkeys — with per-client captcha and device attestation behind them. Nothing to remember, nothing to leak.

Standard OIDC

Discovery, PKCE, rotating refresh tokens, JWKS, token exchange. Works with anything that speaks OpenID Connect, and with Supabase's third-party auth.

Yours

Each product keeps its own brand and its own door — logo, backdrop, templates, even the sign-in hostname. Latchkey just cuts the keys.

Enterprise SSO

Your customers bring their own IdP: verified domains route sign-ins to their Okta or Entra, groups map to access, head office covers every location.

Tenants, teams and roles

Model your product's own multi-tenancy — tenants under optional enterprises, teams that confer access, your own role vocabulary in every token.

Keys and webhooks

Show-once API keys for your customers' machines, publishable keys for their browsers, and signed webhooks that keep your database in step with every membership change.

How it goes

Three steps to a signed-in user.

01
Register a client
One line of Terraform or a form in the console: name, redirect URIs, public or confidential.
02
Send them to the door
Authorization code + PKCE from your SPA, mobile app or server. Latchkey emails the link, checks the code, or asks for the passkey.
03
Read the token
RS256 JWTs with your tenants and roles in the ns claim. Verify against the JWKS; keep no session state you did not want.

In practice

Built to run a product, not a demo.

The console

Every org runs itself.

Clients, users, members, sessions, mail, branding and auth domains — org owners do all of it without a ticket to staff.

console.latchkey.id/o/northcote-cafe/clients

Org

Clients

Users

Members

Sessions

Settings

Name	Kind	Last used
cafe-portal	public · PKCE	2m ago
cafe-mobile	public · phone	9m ago
cafe-backend	confidential	just now

Audit

Who signed in, from where.

Mail

Your sender, your templates.

Per-org SendGrid, login and invite templates with a strict variable allowlist, delivery visibility down to the bounce.

Infra as code

A Terraform provider.

Orgs, clients, auth domains, branding and templates as code — the same way the rest of your stack is.

Trust

Run on Google Cloud, in the US.

RS256 with key rotation, sealed secrets under Cloud KMS, an event log for everything. The service runs on Cloud Run in us-east4; its database is in us-central1.

Questions

The ones we get asked.

Do my users need an account with Latchkey?

No. An identity is an email (or a phone number) the first time it signs in through your client. There is nothing for them to create or remember.

Can I keep my own database of users?

Yes — Latchkey vouches for who someone is; what they may do is yours. Signed webhooks keep your tables in step with memberships, and token exchange lets your backend mint tokens other systems trust.

Can I use it, or run it myself?

Not yet. Latchkey is identity infrastructure for the house products, invitation-only, and not yet offered to outside developers. Its source is private.

Let yourself in.

Latchkey signs people in to the house products today, by invitation. Already in? Register a client, send your first user to the door, read the token.

Open the console Quickstart