The sign-in service no longer has a database of its own
Rutba’s sign-in kept its own database: sessions, keys, second-factor challenges, an audit trail, and a second copy of everybody. Since 21 September it keeps nothing. Every record it needs lives in the one backend that already held people.
· 3 min read
For most of its life, Rutba’s sign-in had a database of its own. Nine migrations’ worth: sessions and refresh tokens, the keys it signs with, second-factor challenges, the short codes that hand a sign-in from one site to another, the state of every sign-in in progress, an audit trail — and, for a mode where the main backend was not set up, a whole second copy of people.
Every one of those was a place for two truths to form. One store for the second factor had already shown what happens when two systems each hold part of a person: a settings page that says one thing and a sign-in that checks another. So on 21 September the sign-in service stopped keeping anything at all.
Where everything went
Not into a new database. The rule the owner set was to reuse what the backend already has before inventing anything, and nearly everything had an obvious home:
| What the sign-in needs | Where it lives now |
|---|---|
| People, passwords, organisations and memberships | The backend that already held people — one copy |
| Sessions and refresh tokens | The backend’s own session manager |
| Hand-off codes between sites | Short-lived rows beside the sessions |
| Signing keys and the register of sign-in clients | The backend’s settings store, the private halves sealed with a key only the sign-in service holds |
| A sign-in waiting for its second factor | The two-factor plugin’s own signed, short-lived challenge |
| “This session was ended” for every app | Events in the platform’s outbox |
| The audit trail and access requests | The types that already existed for them |
Why it is worth the trouble
- One copy of a person. Suspending an account, changing a password or removing a second factor happens in one place, and the sign-in reads it there — there is no second table to forget.
- Fewer things to back up and to secure. A database holding sessions and signing keys is one of the most sensitive things an estate runs; the best version of it is the one that does not exist.
- Nothing to keep in step. The sign-in service can be rebuilt or moved without migrating anything, because there is nothing of its own to carry.
The safest database of sessions and signing keys is the one that is not there.
Tested without a database, on purpose
A service with no store is only as good as its tests against the one it uses. They now run against a stand-in for the backend that answers over HTTP exactly as the real one does — the identity, second-factor and sign-in-state doors — and every suite that used to need a database runs everywhere, none skipped: four hundred and fifty-seven tests, with the drill for rotating signing keys among them rather than a script somebody runs by hand.
What it cost
Everybody was signed out once, when production switched over late on 21 September — sessions do not survive a change of where sessions live. The old database was kept rather than dropped, so there is something to look back at if anybody needs to. And the sign-in service now needs the backend to be up to sign anybody in, which it already did: that is where passwords were checked all along.
