I maintain Warden, the authentication library behind Devise in Ruby on Rails, originally created with Daniel Neighman. It has over 125 million downloads. It authenticates millions of users every day. I later worked at NCC Group, one of the largest cybersecurity firms in the world, building products designed to withstand nation-state attacks.
Here’s the thing I wish every engineering leader understood: the biggest mistake teams make with auth isn’t the initial implementation. It’s underestimating the maintenance.
The build is the easy part#
Building an authentication system is a well-documented problem. There are tutorials, patterns, and libraries for every language and framework. A competent engineer can wire up password hashing, session management, and JWT tokens in a week. It will work. It will pass code review. It will ship.
And then it will sit there for years.
That’s where the real cost lives. Authentication isn’t a feature you build once. It’s infrastructure you maintain forever. Every zero-day vulnerability in a hashing algorithm, every new attack vector against JWTs, every CVE in a dependency you forgot you had: all of it is your problem now. And the team that built the auth system three years ago? Half of them have left the company.
Nobody staffs for zero-days#
Here’s the pattern I see over and over. A team builds auth in-house because “our requirements are unique” or “we don’t want the dependency.” The implementation is solid. Everyone moves on to product work. Six months later, a vulnerability drops. Maybe it’s an algorithm confusion attack or a signature forgery vulnerability in your JWT library. Maybe it’s a timing side-channel in the password comparison. Maybe it’s something in a transitive dependency that nobody realized was even in the stack.
Who fixes it? The original team has moved on. The engineers who understand the auth code at a deep level are now building other things. There’s no standing team responsible for authentication maintenance, because nobody planned for that. Auth was a project, not a product.
With a well-maintained community library, that zero-day is someone else’s full-time problem. Not because you’re being lazy, but because a library with millions of users has millions of reasons to find and fix vulnerabilities fast. The odds of your internal team spotting a subtle attack vector before a community of thousands? Slim to none.
“Just throw an AI agent at it”#
I can already hear the counterargument: “We’ll set up an AI agent to monitor our auth dependencies for vulnerabilities. Problem solved.”
No. Auth security requires deterministic, auditable decisions, not probabilistic ones. An AI agent can hallucinate that a CVE doesn’t apply to your usage. It can miss a subtle attack vector because it wasn’t in the training data. It can give you false confidence that everything is fine when it isn’t.
And when the breach happens, “the agent said it was fine” doesn’t hold up in a postmortem, a compliance audit, or a courtroom. You need to know who reviewed what, when, and why they made the call. That’s a human accountability problem, not a monitoring problem.
AI tooling can help surface issues faster. It’s a reasonable part of a security workflow. But it’s not a substitute for a team that owns auth as a product and makes deliberate, documented decisions about every vulnerability that comes in. The moment you treat security as something you can fully delegate to automation, you’ve created the exact staffing gap this article is warning about, just with a shinier label on it.
The JWT checklist that should scare you#
Since we’re here, let me share the shortlist of JWT pitfalls I’ve seen teams miss. These aren’t theoretical. They’re the ones that go unnoticed for years:
- Always validate the
algheader before processing the body. Thealg: noneattack is one of the oldest tricks in the book, and I still see implementations that don’t check for it. - If you’re using HS256, consider RS256. Symmetric algorithms are vulnerable to brute force if someone gets hold of a token. Asymmetric algorithms (RS256) eliminate that vector entirely.
- If you’re using elliptic-curve cryptography, verify that public keys are valid curve points and private keys sit inside the valid range. Invalid curve attacks are real.
- Check every claim:
exp,iat,aud,sub,nbf. Don’t trust the payload until you’ve verified all of them. Skipping one is an invitation for token reuse attacks.
Each of these is documented. Each of these is a solved problem in mature libraries. Each of these is something a team rolling their own auth has to discover, implement, and maintain by hand. Forever.
What I’d do differently with Warden#
Warden has been rock-solid for over a decade. It does exactly what it was designed to do, and it does it reliably. But I learned something uncomfortable about open source: stability gets mistaken for abandonment.
The library hasn’t had a meaningful change in nearly ten years because it doesn’t need one. The authentication layer it provides is complete. But people look at a quiet commit history and assume the project is deprecated. They move on to newer, flashier alternatives that may be less battle-tested but look more “active.”
If I could do it over, I’d push out regular releases even when the changes are minor. Better documentation, more use-case examples, clearer communication about what “done” looks like for a library. The technical lesson is that Warden’s architecture was right. The leadership lesson is that perception matters as much as reality, and maintaining trust with your user base requires active communication even when the code doesn’t change. That lesson, by the way, applies to a lot more than open source.
The decision framework#
If you’re an engineering leader deciding whether to build auth in-house or use an established library, here’s how I’d frame it:
Build in-house if you have a genuinely unique authentication requirement that no existing library can support, AND you’re willing to staff ongoing maintenance for the lifetime of the system, AND you have security expertise on the team to evaluate emerging attack vectors continuously.
Use an established library if any of those conditions aren’t true. Which, for most teams, means use the library.
The cost of auth isn’t the sprint it takes to build it. It’s the decade of vigilance it takes to keep it safe. Plan for that, or let the community carry it for you.