On 16 October we read the sign-in code of every app and site we run and graded each one. The answers did not match. One app had passwords with authenticator codes. One used a hosted auth vendor. Others had rolled their own email links, codes or long-lived tokens. Microsoft sign-in existed nowhere.
So we wrote one standard and adopted it the same day. It is short enough to state in a sentence: sign in with a six-digit emailed code, Apple, Google or Microsoft; get a session that is ours, opaque and revocable; and nothing else.
What we turned down
SMS codes were never close. They cost money per message and they can be stolen by a SIM swap, which is a phone call to a mobile network away. An emailed code does the same job without the SIM swap or the text-message bill, over a channel we already have to protect anyway.
Four methods cover the people we build for. Consumers have Apple and Google. Businesses run on Microsoft or Google. Everyone else has an email address. Apple’s App Review Guideline 4.8 asks any App Store app that offers third-party social sign-in to also offer an equivalent privacy-focused login option, and Sign in with Apple is one way to meet it, so it is in by default rather than added at review time. The email code is always visible, on every screen, because it is how someone gets back in when they lose access to a provider account.
The code itself has rules. Six digits from a proper random source, stored only as a keyed hash. Ten minutes, one use, and a few wrong guesses burn it. Requests are rate limited per address and per IP address, with a pause between codes to one address. The request always answers the same way whether or not the address has an account, and the email goes out after the response, so not even the timing gives it away. The email says “Your code is” followed by the number, in plain text, so phones can offer to fill it in.
The rule that stops a takeover
The hardest part of sign-in is not proving who someone is. It is deciding when two sign-ins are the same person.
The tempting rule is to match on email. Someone signed up with an emailed code as [email protected], later taps Sign in with Microsoft, Microsoft says the email is [email protected], so attach it to the same account. That rule has a known hole, sometimes called nOAuth. On a Microsoft work account the email field is not necessarily verified: whoever controls a tenant can set it. Match on it and anyone with their own tenant can walk into someone else’s account.
So the standard says this. A person is a user, and each way they sign in is an identity, keyed by the provider’s stable id, never by email. A known identity always signs in to its own user. A new identity may join an existing user by email only when the provider asserts the email is verified: Google and Apple say so explicitly, Microsoft personal accounts qualify, and work accounts only with the claim that says the domain owner verified it. An unverified email can create a new account, flagged as unverified, but can never attach to an existing one.
And if the real owner of that address turns up later and proves it, every session on the account is revoked first, then every identity that did not itself prove the address is removed, however it got there. The order matters: revoke first, so a link made from a live session cannot survive the repair.
Sessions that are ours
A session is 256 random bits, not a signed token that stays valid until it expires. The browser holds it in a cookie scripts cannot read. A phone holds it in the keychain. Our database holds only its SHA-256 hash. Sessions last 30 days idle and 90 at most, unless an app writes down something shorter, and staff tools should run 12 hours. Signing out, signing out everywhere, disabling an account and deleting one all work the same way: revoke the row. Nothing waits for a token to time out.
Two caveats we accepted with open eyes. The code emails go through Cloudflare’s email service, which is still in beta, so every app that already had another sender keeps it as a fallback. And Microsoft is new everywhere: the first real app registration has to be done once per business before the button can switch on.
The client portal moved onto the kit on 16 October, the day the standard was adopted, with Google, Apple and the emailed code, and its old login was deleted the same day. ZooLog, which still signs people in through a hosted vendor, is next.
Update, 7 November 2026
ZooLog moved on 18 October: its server now issues our own opaque sessions from D1, verifies Apple, Google and Microsoft sign-in itself through the native routes, including the verified-domain check for Microsoft work accounts, and keeps a compatibility route so phones already signed in can swap their old tokens for new sessions. The switch was flipped on production on 19 October, with very few active users, so we did not wait for a daytime slot. The old token path is due to be deleted on 29 November. Microsoft’s own app was registered on 18 October and its sign-in button went live the next day, correcting the caveat above: by the time we wrote it, the registration it describes was already done. What was still open when we checked, on 2 November, was a real Microsoft account walking through it on a device, and a smaller piece: the browser fallback used only by Apple sign-in on Android and the web, built and shipped on 21 October but waiting on a director to add two redirect URIs before it answers.
