Your Login Method Is One if-Block Away From Disaster

There’s a pattern that fixes it — and one of the most-used auth libraries on the planet named itself after it.

Day 1 of a series: one design pattern a day, each anchored to something you’ve actually used.

You built login on a Tuesday. Email and password. It worked, you shipped it, you felt good about it.

Then the message came: “Can we add Sign in with Google?”

Easy enough. You wrapped the new logic in an if. If the provider is Google, do the Google thing; otherwise, fall back to the old email flow. Clean. You shipped that too.

Then came Apple. Another if. Then GitHub, because someone read that developers love it. Then phone OTP, because a voice in a meeting asked, "what about users without email?" And somewhere in there — without any single moment you could point to — your authenticate method quietly turned into a swamp.

Here’s the part that should worry you. This isn’t just ugly — it’s dangerous. That one method now guards your entire application. Every new provider means opening it back up and operating on the single class that stands between your users and their accounts. And when something breaks in there, it doesn’t break for Google users. It breaks for everyone. The email users who’ve logged in the same way for two years go down because you were adding a button for GitHub.

You’ve concentrated all your risk in the one place you can least afford it.

The fix has a name — and a library named itself after it

Sign in with Google. Sign in with Apple. Continue with email. Send me a code.

Four buttons. Four completely different mechanisms behind them — OAuth handshakes, token exchanges, password hashing, one-time codes. And yet, from your application’s point of view, they all do the exact same job and hand back the exact same thing: “this person is who they claim to be.”

Different doors. Same room.

Your app doesn’t care how someone proved their identity. It cares only that they did. And the moment you notice that — that the goal is fixed but the method is interchangeable — you’ve found the shape of the Strategy pattern.

The idea is almost embarrassingly simple once it clicks. Instead of one giant method that knows how to do everything, you define a single promise — a common interface — and then let each way of keeping that promise live in its own small, self-contained class.

And the code that actually runs login? It gets to be almost boring 🥱 :

Read that login method again. It has no idea whether it's talking to Google or Apple or an email form. It doesn't want to know. You hand it a strategy, it runs the strategy, it gets back a verified user. When product asks for "Sign in with GitHub" next quarter, you write one new class — GitHubAuth — and this method never changes. The blast radius of a new feature shrinks from "the class that guards the whole app" to "a file nobody else depends on."

That is the entire payoff of the pattern in one sentence: new behavior arrives as new code, not as edits to old code.

If you think this is just textbook theory

It isn’t, and here’s the proof I like best.

Passport.js is one of the most widely used authentication libraries in the Node ecosystem — it sits behind a staggering number of real production apps. Go look at how it’s built. Its plug-in modules are called **GoogleStrategy, `LocalStrategy**,FacebookStrategy`. The maintainers didn't just use the pattern; they named the code after it. Spring Security does the same thing in spirit, with pluggable authentication providers you swap in and out.

When someone in your comments asks, “yeah but is this really the Strategy pattern?” — you don’t have to argue. You just point at a library that answered the question by naming itself after it.

One honest distinction that’ll make you sharper than most:

Here’s a trap worth avoiding, because getting it wrong is what makes a lot of design-pattern content feel hollow.

The button you tap is not the pattern. Choosing “Sign in with Google” is just you giving input — a selection. The Strategy pattern is what happens behind that choice: the swappable authentication algorithm that runs once the selection is made. Keep that line clear in your head and you’ll never mistake a UI toggle for an architectural decision again.

And one more piece of honesty, because scale changes things. At a small or medium app, the interface-plus-classes version above is exactly what you’d build and it’s exactly right. At the size of a company running hundreds of auth flows across dozens of regions, the same idea often lives in configuration or a rules engine rather than hardcoded classes — because you can’t redeploy the world every time one flow changes. But that’s not a different pattern. That’s Strategy that grew up. The shape is identical: interchangeable behaviors, selected at runtime, behind a stable interface.

So when do you actually reach for it?

Use Strategy when a single job has many interchangeable ways of getting done, and the choice is made at runtime — payment methods, authentication providers, pricing rules, compression algorithms, export formats. Any time you catch yourself writing “if it’s this type, do that,” and you can feel more types coming, that’s the signal.

And skip it — this matters just as much — when there’s only ever going to be one way. Wrapping a single, stable behavior in an interface and a strategy class doesn’t make you clever; it makes the next person open five files to understand one decision. Don’t pattern-ify a coin flip.

The best engineers I know aren’t the ones who memorized all twenty-three patterns. They’re the ones who feel the pain — the swamp forming in the login method — early enough to reach for the right tool before the risk piles up in one place. Strategy is the first tool worth having in that reflex.

This was Day 1. If it was useful, follow along — I’m breaking down one design pattern a day, each tied to code you’ve actually shipped. Tomorrow: Observer, the pattern quietly running behind every “subscribe” button you’ve ever tapped.