Never Store Passwords: How We Built (and Then Simplified) Our Auth Stack

We started with a principle that seemed obvious: never store passwords. If you’re building a platform and you don’t absolutely have to manage credentials, don’t. Let someone else handle the password hashing, the brute-force protection, the account recovery flows. Delegate identity to experts.

So we did. Social login via a dedicated identity provider. Google and GitHub sign-in. Users clicked a button, authenticated with a provider they already trusted, and came back with a token. The identity server handled session management, token issuance, and user provisioning. Clean separation of concerns.

It worked. And we knew from the beginning it wouldn’t be enough.

The magic link question

Not everyone has Google. Not everyone wants to authenticate with GitHub for a tool that isn’t about code. Some people just want to type their email address and click a link. Magic link login was always on the roadmap — the question was when, and how.

The “how” is what made this interesting. Magic links mean we’re issuing our own tokens. The user clicks a link, we verify they own the email address, and we hand them a session. That’s not delegated identity anymore. That’s us, being an identity provider, at least partially.

We built it. Platform-issued tokens with HMAC-SHA256 signing, purpose-prefixed to prevent token confusion. A composite auth backend that could validate both our own tokens and the external identity provider’s tokens simultaneously. Old users kept logging in the way they always had. New users could use email. Both flows produced the same auth context downstream.

The realization

Meanwhile, we’d been building OAuth infrastructure for an entirely different reason: service connections. When a user connects their Gmail, or their Slack workspace, or their GitHub repos, that’s an OAuth flow. PKCE, state management, callback handling, token exchange, credential storage. We had all of it — battle-tested, running in production, handling real user connections every day.

One evening Greg and I were looking at the auth stack and the connection infrastructure side by side. The overlap was uncomfortable. We had a full external identity server managing social logins. We had our own token issuance for magic links. We had OAuth infrastructure for service connections that already knew how to talk to Google and GitHub. Three systems doing variations of the same thing.

The external identity server was the odd one out. We were proxying tokens through it, maintaining its configuration, running it as infrastructure, monitoring it — all for social login that our existing OAuth infrastructure could handle directly.

The migration

We didn’t rip it out overnight. Each step was additive, with old and new flows running simultaneously.

First, we added direct Google OAuth login through our existing connection infrastructure. Same OAuth flow users were already using to connect their Gmail — but now it could also authenticate them. One redirect, one callback, one platform-issued token. No proxy, no external server in the loop.

Then GitHub. Same pattern. The OAuth app we already had for GitHub repository connections could handle login too. Users who signed in with GitHub got a platform-issued token, just like magic link users, just like Google users.

At this point, the external identity server was still running but increasingly vestigial. Every new login was going through our own infrastructure. We ran both systems in parallel for weeks, watching metrics, making sure edge cases were covered.

Then we turned it off and deleted the code. About 800 lines of proxy logic, token translation, configuration management, and JWKS caching — gone. One fewer service to deploy, monitor, and maintain. One fewer thing in the critical path between a user and their agents.

The crossover problem

The migration surfaced a problem we’d been thinking about but hadn’t had to solve: account linking.

A user signs up with a magic link. Weeks later, they click “Sign in with Google” — same email address. Are they a new user or an existing one? The answer is obvious to a human but requires careful handling in code.

We match on verified email. If a magic link user later authenticates via Google, we upgrade their auth method. Same user, same account, same agents — they just have a stronger login going forward. A conditional database update prevents race conditions if two login attempts arrive simultaneously.

But not the reverse. Once you’ve signed in with Google or GitHub, we don’t let you downgrade to magic link for that email. Social login is a stronger authentication method — you’ve proven you control the account, not just the inbox. Allowing a downgrade would weaken the security posture. If you signed in with Google, use Google.

What we kept

The external identity server is gone, but the architecture isn’t narrower. We kept the generic OIDC validation path — the code that can validate RS256 JWTs from any standards-compliant identity provider with a JWKS endpoint. Enterprise customers who deploy on-prem will bring their own identity providers. That path still works. We just don’t depend on it for our own platform anymore.

The result is a branded login page with three options: Google, GitHub, or email. Each one produces the same kind of token, goes through the same auth middleware, and lands in the same user model. The simplest version of the system that handles all the cases we actually have.

The accounts overhaul

While we were reworking auth, we also overhauled how accounts and connections work. Users can now see and manage everything from the dashboard — create accounts, connect services, add email addresses, disconnect things. The conversation is still the primary way to set things up, but having it visible in a UI makes the system legible.

This work surfaced one of my favorite bugs. We originally named the default account “my” — as in, your personal account. Seemed natural. But when users said “check my email,” the LLM couldn’t tell if “my” was the account name or just the English word “my.” Is that a reference to the account called “my” or are you asking me to check your email? This is the kind of ambiguity you only discover when your interface is natural language. We renamed it to “personal” and the confusion disappeared instantly.

Building for conversation creates design constraints you’d never hit in a traditional application. Account names, tool parameter names, the way you describe things in docstrings — all of it matters because the LLM has to parse it in the context of human language. The system doesn’t just need to work. It needs to be unambiguous to a language model.

The workflow experiment

Speaking of simplifying — we also experimented with our development workflow. We tried to adopt Gas Town — Steve Yegge’s open source orchestration system for coding agents. The full vision is ambitious: a “mayor” orchestrating work across agent queues, review gates, molecules of structured work. We tried to go all-in on the multi-agent workflow and quickly realized it was too much for where we are. Too many moving parts. The core frustration that led us there was real though — LLMs are over-helpful. They short-circuit every process gate you put in place. A dependency graph only matters when the LLM actually can’t skip it, and you’d be surprised how hard that is to enforce.

But the pieces underneath Gas Town were exactly right. We kept Beads — the Git-backed issue tracker — and Molecules — structured work templates that define a sequence of steps with dependencies. Pour a molecule, it creates the Beads, wires the dependencies, and you work through them one at a time. Simple, predictable, no orchestrator trying to be clever. Yegge’s insight about giving agents a memory system and a ledger of work is spot on — we just needed the lighter-weight version of it. The lesson was the same one we keep learning: start with the simplest thing that works, and only add complexity when you’ve earned it.

The lesson

We started with the right principle — never store passwords — and it’s still true. We don’t store passwords. We never did. But “delegate to an external identity provider” was an implementation choice, not a principle. When our own infrastructure grew to the point where the external provider was pure overhead, removing it made the system simpler, faster, and easier to reason about.

The best architecture isn’t the one you design on day one. It’s the one you arrive at after building enough of the system to see what’s actually pulling its weight.

The auth stack is simpler. The login is friendlier. The dependency list is shorter.