Your coding agent will happily build you an auth system. That's the Problem.
Ask Claude, Cursor, or Copilot whether you should build your own authentication or use a provider, and more often than not it will hand you working code. Password hashing, session cookies, a login form, maybe even a passkey flow if you ask nicely. The agent is capable, so the answer defaults to "build it." That's the wrong answer, and it was the wrong answer before agents could write the code too. Agents didn't change the calculus on build vs buy for auth. They changed who's capable of building the wrong thing faster.
Why does an AI agent recommend building auth instead of buying it?
Because "build it" is the path of least resistance for a model optimizing for the next request, not for what happens six months later. An agent can generate a login form, a bcrypt hash, and a JWT in under a minute, and that output looks like progress. It has no stake in the CVE that gets filed against your token refresh logic next year, no memory of the last time a homegrown session store leaked, and no incentive to say "this is a bad idea" when "here's the code" is the more satisfying answer to give. Speed at the moment of asking is not the same as speed to a secure, maintained system, and the agent only sees the former.
The skills gap hasn't closed, it's moved
Before agents, the barrier to building your own auth was: do you have the time and the expertise to do it right? Agents removed the time constraint. They did not close the expertise gap, they just moved it downstream. Now you have someone who can produce the code, but the person reviewing it still needs to know what a timing attack looks like, why refresh token rotation matters, or that storing a password reset token in a way that's guessable is a vulnerability, not an implementation detail. Generating code and knowing whether that code is secure are two different skills. An agent gives you the first one. It doesn't give you the second.
That gap shows up worst in code you didn't write yourself. When a human writes their own auth stack, badly as it may be, they at least built a mental model of it as they went. When an agent generates it in one pass, nobody on the team has that model. Six months later, when a security researcher or an internal audit flags something in the token handling, the team is debugging a system nobody actually understands, written by something that has already forgotten it and moved on to the next task.
Finding a vulnerability in code you didn't write is harder, not easier
This is true regardless of who or what wrote the code, but it's worse when an agent wrote it, because the volume of code an agent can produce in an afternoon is easy to generate and hard to audit at the same pace. A senior engineer reviewing 200 lines of hand-written auth code can reason about intent, because they can ask the person who wrote it. Reviewing 2,000 agent-generated lines with no author to interrogate means the reviewer has to reconstruct intent from scratch, line by line, in the one part of the codebase where a missed assumption becomes a breach instead of a bug.
Security vulnerabilities in auth systems are rarely obvious. They're edge cases: a state parameter that isn't validated, a redirect URI that isn't strictly matched, a session that doesn't actually invalidate on logout. Catching those requires knowing the standards well enough to know what's missing, not just reading the code that's there. That's exactly the review this agent-written homegrown auth needs, and exactly the review most teams that reach for "just have the agent build it" aren't equipped to do.
Auth is not a feature you finish, it's a standard you keep up with
Build it once and the work isn't done. OAuth and OIDC specs evolve. New attack classes get published. Passkeys went from novel to expected in about two years. Whoever owns your homegrown auth system now owns tracking every one of those changes, indefinitely, on top of their actual job. A dedicated identity provider's job is to track this so you don't have to. That's not a marketing line, it's a division of labor question: do you want your team's time spent keeping up with the IETF, or building your product?
What "just username, password, and passkey" turns into
The auth system that felt sufficient at 200 users doesn't stay sufficient. Growth adds requirements nobody scoped for at the start:
- A prospect's security team requires SSO before they'll sign the contract
- Enterprise customers want their own login branding, not yours
- You need per-customer configuration: session lifetimes, MFA policy, allowed identity providers, all different per tenant
- Multi-tenancy stops being "a column in the users table" and becomes an actual isolation and permissions model
- Someone asks for an audit log of who logged in, from where, and when, because a customer's compliance team asked
None of this is exotic. It's the standard shape of what a B2B product needs the moment it has real customers. A homegrown auth system built for username/password/passkey has to be substantially rebuilt to support it. An identity provider already has it built.
When building your own auth actually makes sense
This isn't "always buy, no exceptions." Building your own has real cases:
- You are an identity provider. Auth is the product, not something in the way of the product.
- Your requirements are genuinely a single, fixed flow with no growth path toward SSO, multi-tenancy, or enterprise customers, and you're confident that stays true.
- You have engineers on staff with real security and identity protocol expertise, and the ongoing headcount budget to keep them on it.
If none of those are true for your team, the agent making it faster to produce the code doesn't change the answer. It just means the wrong decision compiles now.
Build vs buy, before and after agents
| Build it yourself | Use an identity provider | |
|---|---|---|
| Time to first login | Fast, faster with an agent | Fast: npx @zitadel/cli@alpha setup gets a working login in under 90 seconds |
| Who owns finding vulnerabilities | Your team, in code an agent may have written and nobody fully understands | The provider, whose entire job is this |
| Keeping up with OAuth/OIDC/passkey standards | Your ongoing responsibility | Handled upstream, continuously |
| SSO, multi-tenancy, branding, per-customer config | Rebuilt from scratch when you need them | Already there |
| Audit trail for compliance | Something you build when a customer asks | Built in |
| What changed with agents | Code generation got faster | Nothing: the review and standards burden is unchanged |
The real question isn't build vs buy, it's who's accountable for what you can't see
An agent can write you a login flow this afternoon. It can't be the one who gets paged when a researcher finds a hole in it, and it won't be the one keeping your token handling current with next year's OIDC update. That accountability lands on your team either way, whether the code came from a human or a model. Buying an identity provider doesn't remove that work, it moves the everyday burden of it to a team whose whole job is exactly that work, so yours can go back to building the product.
If you're deciding this for a new project, the fastest honest test is to run both paths side by side: ask your agent to scaffold auth, and separately run npx @zitadel/cli@alpha setup to see what a working login looks like when someone else already did the standards work. Compare what you have to maintain in six months, not what compiles today. If you want to see the fuller thinking behind that setup command and what we're building it toward, we wrote about it in the Zitadel next iteration preview.