Building Your Own Authentication

TL;DR: A working login takes an afternoon. What costs money is everything that keeps it correct afterwards: password hashing that has to be tuned, keys that have to rotate, protocol guidance that changes, passkeys and recovery flows, abuse protection and an audit trail. This article lists those ongoing costs with sources, says honestly when building your own is the right call, and shows how to price the alternative.

What "from scratch" actually means

The phrase covers three very different things, and most of the confusion in this debate comes from mixing them up.

ASP.NET Core Identity is not "from scratch". Microsoft's documentation describes it as managing users, passwords, profile data, roles, claims, tokens and email confirmation, with support for external providers. If your need is one web application with its own user store, it is a perfectly reasonable foundation, and nothing below argues against it. The argument is about the point where that stops being enough, and about the second row of the table, where you still own a lot.

What sits under the login form

Each item below is a piece of work that does not end when the feature ships.

Password storage that has to be upgraded

OWASP's Password Storage Cheat Sheet covers Argon2id, scrypt, bcrypt and PBKDF2, and treats the work factor as something you raise over time as hardware gets cheaper. Its usual approach is to re-hash a password with the new settings the next time the user signs in. ASP.NET Core Identity's default hasher uses PBKDF2 with a default of 100,000 iterations, writes a version marker into every hash so older ones still verify, and can report that a correct password should be re-hashed. A hand-rolled scheme needs that upgrade path designed in from day one, which is easy to skip and hard to add later.

Keys that rotate, persist and survive a deployment

ASP.NET Core's Data Protection system, which protects cookies and many other payloads, creates keys with a default lifetime of 90 days and rolls them automatically. It also documents the trap: unless the environment provides a persistent location, keys are not persisted outside the process, and in a container they should be stored on a volume or in an external provider. Deleting a key makes everything protected with it permanently unreadable. None of this is exotic, but each deployment target needs someone to have thought about it. A token server adds signing and encryption certificates on top, with their own expiry dates and their own rotation.

A protocol that keeps moving

RFC 6749, the OAuth 2.0 core specification from 2012, was updated in January 2025 by RFC 9700, the current best-practice document for OAuth security, which also updates RFC 6750 and RFC 6819. It asks for exact redirect URI matching and PKCE for public clients, advises against the implicit grant and forbids the password grant. An implementation that was reasonable when you wrote it can drift out of line without a single line of your code changing. We walked through the practical consequences in What happens when your authentication is misconfigured.

Passkeys, second factors and the recovery question

.NET 10 added passkey support to ASP.NET Core Identity, which is a real step forward, and its documentation is candid about the edges. Passkeys are treated as a primary sign-in factor, not as a second factor. Attestation statements are not validated by default. Only the Blazor Web App template includes passkey support out of the box. For apps that allow passkeys as the only credential, recovery is left to you: the documentation suggests recovery codes, email-based flows or requiring several passkeys. It also notes that you may need to revoke credentials if a particular authenticator model turns out to be vulnerable. Microsoft's multi-factor authentication documentation adds that SMS as a second factor is no longer recommended, pointing to NIST's digital identity guidelines. Choices like these are product decisions that someone has to own and revisit.

Abuse protection and an audit trail

Lockout, rate limiting and detection of credential stuffing are not features you build once. They need tuning against real traffic, and OWASP keeps a separate cheat sheet on credential stuffing prevention for a reason. When something does go wrong you want to answer who signed in, who failed, which account was locked and which tokens were revoked. That means recording security events deliberately, from the start, in a form you can query.

When building it yourself is the right call

It is a short list, but it is not empty:

• One application, one user store, no third-party clients. ASP.NET Core Identity alone is enough, it is maintained by Microsoft, and adding an OpenID Connect server would be over-engineering.
• Authentication is your product. If you are building an identity provider, you own all of it by definition.
• A constraint that rules out third-party components. Some environments do not allow them. Then the maintenance list above is the budget you are signing.
• Learning. Building a small authorization server once is the best way to understand one. Just do not point real users at it.

What changes the answer is growth in the requirements: a second application that should share the sign-in, a mobile client, an API consumed by someone else, partners who need tokens. At that point you are no longer adding a login to an app, you are operating a token server, and the second row of the table above becomes a project.

Buying is not free of work either

A packaged server or a cloud service moves the maintenance, it does not remove it. You still configure it, upgrade it and watch what it does. And you take on vendor risk, which is real: IdentityServer4's end of life left many teams with an unpatched server in front of their login. Before you choose anything, check who maintains it, how recently it was updated and what happens to you if that stops.

For a .NET team that wants a self-hosted token server with the work above already done, IdentitySuite is one option. It is built on OpenIddict and ASP.NET Core Identity, and the settings files that ship with it include:

• Passkey sign-in, switched on in the shipped templates, alongside authenticator-app two-factor authentication and recovery codes.
• Sign-in with Google, Microsoft, Facebook, GitHub, LinkedIn and Apple.
• Lockout after repeated failures and rate limiting per endpoint class, both enabled in the templates.
• Built-in signing and encryption certificates that are rotated automatically as they near expiry, with an expiry alert, instead of keys you manage by hand.
• A security audit log with sign-in successes and failures, lockouts, two-factor events, passkey events and token revocations.

It does not remove the maintenance entirely: you still run it, configure it and keep it updated, and it is a younger product with a smaller ecosystem than the established ones. If you want to see what adopting it looks like, the Authentication Made Easy article adds authentication to a single-page app with it.

How to price the decision

I will not invent a number of person-months for you; it depends on your team and your requirements. The comparison is easier than it looks, though. List the capabilities above that you need, estimate the first build and the yearly upkeep for each in hours, and multiply by your own hourly cost.

Then compare that with the price of the alternative. IdentitySuite's Standard plan is €349 per year. As an illustration only, at an assumed €60 per hour that is under six hours of one developer's time. The question is whether you would spend more than that in a year on key rotation, upgrades, checking security guidance and reading audit logs, before writing any feature at all. Use your own rate; the shape of the answer rarely changes.

If you want to see what each plan includes, the pricing page has the details.