Precious Mae

Posted on Mar 1

Back to Basics: A Developer’s Guide to Authentication

#cybersecurity #webdev #auth #beginners

Authentication (AuthN) is a crucial aspect of building systems and creating web applications, and could make or break your customer's trust. Microsoft Security (2026) defines authentication as the process that companies use to confirm that only the right people, services, and apps with the right permissions can get organizational resources. It proves who the user is. This differs from authorization which controls what the verified user is allowed to do or what they can access. These two security processes are interconnected, with authentication always happening first followed by authorization.

Why should we care?
Why bother with the basics?
How does the web work? (And why you, as a developer, need to know)
How do we authenticate?
Multi-factor authentication: Layering your defenses
Common Authentication Services: From Factors to Platforms
So... which one should you pick?
Further Reading & References

Why should we care?

In the digital age, data is power. Every company and their mother is trying to get access to your data because that is how they make you come back. Your every action online is logged into a system that builds your online identity or profile from a company's point of view. For example, your YouTube algorithm has been collecting data to make sure that the videos it recommends make you stay on the app longer, which in turn allows them to show you more ads which means more revenue for them. This kind of practice is normal and is actually the industry standard (though digital privacy has been a rising concern due to some shady practices).

This is where I'd normally go on a long tangent about online privacy, staying safe online, the attention economy, and late-stage capitalism in general. But I'm talking to developers—the people building the systems (hi, im part of that too :3). So I'll spare you. For now.

When you build a system, you want your users to stay and come back for more. Saving their information not only makes the use of your app easier for them, but also allows you to customize and improve their experience while using it.

However, this means that your customer's data is not only valuable to you, it's also valuable to bad actors. A bad actor's first priority and step is always to gain unauthorized access to your systems. And if they get your customer's data, that's company image and customer trust gone. And there is no "company" without users. More than that, you are also required to comply with different governmental laws and standards (like the Data Privacy Act of 2012 of the Philippines).

We've established why we, as developers, should care about protecting user's privacy. Here's the part where you'll usually find articles just listing out different authentication services and methods, but this is my article and I say I yap some more.

Because data travels across networks we don't control, we need to understand that journey before deciding how to protect it. Data has three states: at rest, in motion, and in use. In this article, we’ll be going over at rest and in motion.

But before we go over all this complicated talk, I'd like to take a minute to discuss why we should learn this.

Why bother with the basics?

A large portion of this article unmasks the processes and methods used in authentication services. You might be thinking: "If I'm just going to use Clerk or Auth0 and delegate my auth to someone else, why do I need to understand TLS or hashing?" Fair question. But here's the thing: authentication services handle the complex parts for you—and while I also believe that they're one of technology's gifts to developers—until you understand what those complex parts are, you're just trusting that they're doing things right. And I don't know about you, but I can't trust anyone that much.

When you understand that TLS protects data in transit and hashing secures it at rest, you can evaluate whether a service is doing those things right. You'll know why they ask for certain configurations, what those "enterprise features" actually protect against, and—most importantly—you'll be able to spot when something feels off. The fundamentals turn you from a copy-paste developer (or a vibe coder) into someone who actually knows what their auth service is doing with their users' data. And that knowledge sticks with you even when you switch services or providers.

With all those covered: here, we define how the web works.

How does the web work? (And why you, as a developer, need to know)

Okay, so we've established why data matters: its valuable and vulnerable. We've also established why you need to understand the fundamentals: blind trust is how you get exploited—both in life and in security. We have to learn how to protect it now. And to do that effectively, we have to put ourselves in its shoes. We have to follow data on its journey.

Imagine your user's login credentials—their email and password—like a physical letter. When they click that "Sign In" button on your app, that letter doesn't just magically teleport to your server. It has to travel across the internet—through a vast network of cables, routers, and servers across the world—that your user doesn't control (and also sometimes gets bitten by sharks ifykyk). This is the data in motion.

Your job, as the developer building the system, is to put that letter in a locked, armored briefcase, protecting it before it starts its journey. That's where understanding the basics of web communication comes in.

I won't dive into every detail (like the exact role of DNS), but it's crucial to understand the two main protocols that carry our data over the web: HTTP and HTTPS.

HTTP (HyperText Transfer Protocol) defines a set of rules used for communicating with web servers for the transmission of webpage data (HTML, images, videos, etc.). When you access a website, your web browser makes a request to a web server for assets and then downloads the responses.

A lot more happens behind the scenes, but we won't be concerned with that. The important thing to note here is that HTTP traffic is sent in cleartext, meaning anyone with network access can intercept and read requests and responses using packet-capturing tools (like Wireshark). It's like sending over the letter in a clear transparent envelope.

The need for secure web communication led to the creation of TLS that is layered below HTTP, which results in HTTPS or HyperText Transfer Protocol Secure.

TLS (Transport Layer Security) is a cryptographic protocol operating at the transport layer of the OSI model, enabling secure communicating over insecure networks by providing confidentiality and integrity. Traffic is encrypted so it is impossible to determine whether the application data is HTTP or another protocol without encryption keys. Think of it as the "armored briefcase" I mentioned earlier.

By using HTTPS, you've ensured the user's credentials arrived safely at your server's front door. But your journey isn't over. Now, you have to deal with the data at rest.

Protecting your data at rest

We've locked the briefcase with HTTPS, and your user's credentials have arrived safely. Now they're sitting in your database, or is at rest. How do you store them safely so that even if an attacker breaks in, they can't steal your users' passwords?

This is where we introduce cryptography and its two core concepts: encryption and hashing. They're often confused and used interchangeably, but they serve different purposes.

Encryption – Two‑Way, with Keys

Encryption transforms data so that only someone with the correct key can read it. It's reversible (i.e. two way). HTTPS uses encryption to protect data in motion—your password is encrypted on the user's device, then decrypted by your server. But after decryption, your server has the plaintext password. Now, if you store it like that, you're one data breach away from disaster (RockYou.com ring a bell to you?).

Worse, if you stored passwords using encryption, a compromise of the cryptographic key would be catastrophic—an attacker could decrypt every stored password all at once.

Hashing – One‑Way, No Keys

If encryption is a two-way street, hashing is a one‑way street (or, irreversible). In hashing, a hash function takes an input (like a password) and produces a fixed‑length string called a hash. When a user signs up, you hash their password and store only the hash. When they log in, you hash the entered password and then compare it to the stored hash. If they match, access is granted. Hashing is what is used to protect your data at rest because passwords need to be verified and not recovered. It ensures that the original password cannot be retrieved.

But just hashing isn't enough. Using the same hashing function for two identical inputs also means two identical hashses. Attackers then can use precomputed tables (or rainbow tables) to reverse common passwords. This is where salting comes in. A unique random value (salt) is added to each password before hashing. Salting ensures that even if two users have the same password, their resulting hashes are different.

Modern algorithms like bcrypt, Argon2, or PBKDF2 are deliberately slow and handle salting automatically. They're the standard for password storage.

Why this matters

If an attacker steals your database, they can only get the salted hashes—not the passwords themselves.

Protecting stored passwords keeps attackers from reading them—but it doesn't explain how we confirm identity during login. How do we verify that the person presenting credentials is truly who they claim to be? This brings us to the core of our topic: authentication.

How do we authenticate?

Modern authentication usually delegates the authentication process to a trusted, separate identity system, as opposed to traditional authentication where each system verifies identities itself. But regardless of who's doing the verifying, all authentication methods essentially fall into one (or more) of three categories, called authentication factors:

Something you know (knowledge-based)
Something you have (possession-based)
Something you are (inherence-based) ### Something you know #### Password-based authentication

This is the most common form of authentication. You prove your identity by demonstrating knowledge of a secret—your password. However, as bad actors have gotten better at stealing passwords, more authentication methods have been developed and are in use today.

To combat this problem, many apps and services have decided to require people to create passwords that use a complex combination of numbers, letters, and symbols, to reduce the risk that a bad actor can brute-force its way with a wordlist like rockyou. But this also creates a usability problem. It's difficult for people to come up with and memorize unique passwords for each of their accounts, and knowing that almost every service online requires you to make an account now, this will easily become unmanageable without a password manager.

Password-based authentication is also similar to PIN-based authentication or Personal Identification Number. Instead of a complex string of different characters though, its a numerical secret often used as a simpler, device-specific knowledge factor, sometimes in combination with something you have (like an ATM card).

Something you have

This factor requires users to prove they possess a specific physical item or device. Meaning, even if an attacker knows your password, they can't log in without an access to your "something".

Token-based authentication

This typically refers to time-based one-time PINs (TOTP), where the user's device and the authentication system generate the same unique number that changes every 30 seconds. If the numbers match, the system verifies that the user physically has the device, without anything being transmitted over the network.

One-time passwords (OTPs)

OTPs are codes generated for a single sign-in event that will expire shortly after they are issued. They can be delivered in multiple ways, such as via SMS, email, or displayed on a hardware token. They are convenient, but its security depends upon the delivery method. SMS can be intercepted through SIM swapping, while email OTPs depend on the security of the user's email account.

Push notifications

When someone tries to sign in, they receive a message on their trusted device asking them to approve or deny the request. However, because users sometimes accidentally approve notifications they weren't expecting, some services combine this with an OTP and the system generates a unique number that the user must enter, making the authentication more phishing-resistant.

Something you are

Biometric authentication

These have become increasingly common in everyday devices like your phone. Biometric data is typically encoded, encrypted, and saved directly on the device itself, not on a remote server. This means the biometric is linked to a specific device—attackers can't use your fingerprint to access your accounts without also having physical possession of your phone or computer.

This approach solves many usability problems with passwords. Users don't have to memorize anything, and the authentication process is nearly instantaneous. From a security perspective, biological features are difficult for bad actors to steal or replicate compared to passwords that can be guessed, phished, or leaked in data breaches.

Multi-factor authentication: Layering your defenses

You've probably noticed that each authentication factor has its own strengths and weaknesses. Passwords can be stolen. Phones can be lost. Biometrics can't be changed if compromised. So how do we build truly robust security?

Here comes Multi-factor authentication (MFA). MFA requires users to present two or more authentication factors from different categories before granting access. This layered approach means that even if one factor is compromised—say, an attacker steals a password—they still can't get in without having the others. It's why almost every account you have on a service makes you add MFA.

When you combine something the user knows (password) with something they have (phone) or something they are (fingerprint), you create a barrier that's exponentially harder for attackers to bypass.

All together now

Data in motion → Encrypt with TLS.
Data at rest (passwords) → Hash with a salt.

- And a secret third thing… (not really but we're not gonna cover it)

All the authentication services we'll discuss later handle password hashing for you. They use best practices so you don't have to have a PhD in cryptography.

Finally! We've covered all the fundamentals, and if you're still here, we will now be discussing what you probably opened this article for:

Common Authentication Services: From Factors to Platforms

Now that you understand authentication factors and MFA, here's where theory meets practice. As a developer, you could build all this yourself—password hashing, session management, MFA flows, account recovery. But should you?

Building production-grade authentication takes 5-12+ months and costs a whole lot of money. More than that, it also requires you to learn a lot of the nitty gritty, like JWTs, session invalidation, etc. And that's just the initial build. You then get to maintain it forever (aww <3), pray you didn't mess up the cryptography, and hope you're handling things the same way the OWASP cheatsheet says you should.

For most teams and projects, using a managed authentication service makes far more sense. These platforms handle the complex, security-critical parts of authentication so you can focus on your actual product. More often that not, these platforms also have more experience and knowledge in building these, so it might be more secure than you just building your own. The right choice depends on your stack, scale, budget, and feature needs.

I know I’m saying too much, but before we jump into the comparisons, you’ll see some concepts that is reflected in almost every service I will mention below. Let me take a quick second to explain them so choosing the best auth for your use case is easier.

OAuth and OpenID connect

When logging in or signing in to apps today, you probably see the button somewhere that says “Login with Google” or “Login with GitHub”. That is OAuth 2.0 and OpenID Connect. These two services are industry standards that have become commonplace and define how authentication and authorization happen across different services. Every platform I’ll be mentioning implement these under the hood, and are essentially managed OAuth/OIDC providers that save you time from implementing the protocols yourself.

Passkeys, passkeys, passkeys.

If you’ve been reading this whole article without skipping through (I doubt), you’ll probably remember the something you are factor I mentioned earlier. Passkeys, or WebAuthn, are its modern evolution. They're phishing-resistant, device-bound, and easier for users than passwords. Your phone's face unlock or fingerprint sensor becomes the authentication method. If you're starting a project in 2026, you should probably care about passkey support.

Have you heard about vendor lock-in?

Authentication is sticky. And just like slime, once it's in your hair (or your system), getting it out is a painful, time-consuming mess. Once users create accounts in your system, migrating them elsewhere is painful—you're either forcing password resets on everyone or building custom export scripts. Some services make this easier (like open-source options) but others make it impossible. When choosing your auth, you have to take into account: “If this platform stops working for me, can I take my users and leave?”

That's it. Now here are some of the authentication services you can look at:

Clerk

If you're just starting off web development and/or building with React, Next.js, or Remix, Clerk is your best choice.

Setup is stupidly simple, and I mean like 15 minutes from pnpm install to having a working sign-in form. Clerk gives you pre-built components like <SignIn /> and <UserProfile /> that you can add to your code and will work with little to no setup. They handle email/password, social logins, password reset flows, error states—everything you'd spend weeks building yourself.

Clerk also covers everything we talked about when it comes to authentication factors. Passwords (something you know), MFA via authenticator apps and SMS (something you have), and passkeys/WebAuthn (something you are/have) all work out of the box. Session management uses 60-second tokens with automatic background refresh, which means users stay logged in without you having to think about it.

When it comes to pricing, Clerk also offers a free tier: 50,000 monthly active users (MAU) are now free in every application, which is more than enough for most startups. Paid plans on the other hand start at around $20/month.

There is a catch though, it's not open source. So if you need or want to run everything on your own infrastructure, Clerk is fully managed and has no self-hosting option.

Auth0

Auth0 is the veteran. It's been around since forever, it's feature-complete, and it's what most companies reach for when they need to check every compliance box. It offers almost, if not, everything—passwords, social login, MFA (SMS, TOTP, push, WebAuthn), passwordless magic links, enterprise SSO via SAML/OIDC. They also have an Actions framework that lets you inject custom code at any point in the authentication flow—pre-login, post-registration, token generation.

But for a one-person team or a simple project, Auth0 may not be best for you since it excels in enterprise features. By that I mean SAML connections, Active Directory integration, comprehensive built logs, etc. which might not be useful for a quick and simple To Do application.

More than that, Auth0 is also very complex, and might be overwhelming. Basic setup takes 4-8 hours, and complex implementations can take you 1-2 weeks. It’s dashboard has so many tabs and options that even experienced developers get lost.

In terms of pricing, free tier covers 25,000 monthly active users. Paid plans on the other hand range from $35 to 150/month for 500 users, and if you’re a startup just starting to get some traction their paid plans might be too much. Also some user reviews complain about pricing complexity and unpredictable scaling costs. So before choosing Auth0 you should probably look more into that.

Firebase Authentication

Firebase Auth is Google's baby, and if you're already in the Google Cloud ecosystem, it's the path of least resistance. It’s particularly strong and used for mobile apps. iOS and Android developers get native authentication flows that feel platform-appropriate.

Setup is straightforward and simple—email/password, social logins, phone auth (SMS), and anonymous authentication all work with minimal configuration. The Firebase SDKs are well-documented and widely used. I’ve personally used this and I would argue its as simple as Clerk’s setup.

Google also offers a generous free tier with 50,000 monthly active users at no cost. Most Firebase products have no-cost usage quotas that reset daily or monthly. If you’re just building a side project, this can be a good contender.

However, if you’re a startup starting to scale, Firebase Auth starts getting more restrictive. Organization and multi-tenancy support is largely manual. MFA exists but requires upgrading to Identity Platform. SAML and OIDC also require upgrades.

Additionally, migrating away from Firebase later is painful. Complex queries and advanced authorization require workarounds. And because it's Google, you're subject to their API limits and rate throttling.

AWS Cognito

Google has Firebase Authentication while AWS has AWS Cognito. Same as with Firebase Auth, if your infrastructure is already on the AWS ecosystem, Cognito makes compliance and architecture simple. User pools manage directories, identity pools provide temporary AWS credentials for accessing other services, and it all stays inside your AWS account.

Cognito takes some time for setup though. Around 1-2 days for basic implementation, and 4-7 days for production-ready. And if you’re unfamiliar with the AWS ecosystem, this might even take longer.

AWS structure its pricing into tiers: Essentials and Plus. Essentials offers basic user registration, authentication, and management capabilities, along with Managed Login and passwordless login options. Plus, on the other hand, is geared toward customers with elevated security needs for their applications and offers threat protection capabilities.

Where AWS makes it money though come from add-ons. SMS messages go through SNS and emails go through SES, all billed separately. And if you enable Advanced Security Features on a Lite tier pool, your bill explodes.

MojoAuth

If you’re modern and want to go passwordless, MojoAuth could be your answer. They have magic links, OTPs, WhatsApp verification, and passkeys.

You might notice I specifically mentioned WhatsApp verification and not SMS. Instead of trying to figure out SMS rates, MojoAuth built WhatsApp login natively. SMS verification costs $0.01–0.05 per message; WhatsApp Business API costs $0.003–0.009, and in countries where WhatsApp is the go-to, it makes more sense.

For developers, it’s lightweight. APIs, a drop-in hosted login page, clean SDKs, and you can probably integrate in under 15 minutes.

In pricing, free tier covers 25,000 monthly active users. Business Pro runs $50/month with unlimited users, passkeys, custom domains, and enhanced attack protection.

MojoAuth’s biggest selling feature is being passwordless. Meaning, if you’re traditional and want passwordless authentication for some reason, you better stay far far away from it. And since it’s new, the ecosystem is smaller.

Supabase Auth

If you want open source, Supabase is a Firebase alternative that could be your choice. Open source also means you can self-host the entire stack and avoid vendor lock-in. Auth comes built-in, which makes it easier if you’re already using Supabase for database and storage. Open source also

The auth layer supports email/password, social logins, magic links, and TOTP MFA out of the box. It's PostgreSQL-backed, which means user data lives in a database you can actually query and join with your application data.

Free tier gives you 50,000 monthly active users at no cost, plus 500MB database and 1GB storage. On the other hand, the Pro plan starts at $25/month and removes project pausing and bumps limits.

Supabase Auth was the first Auth service I ever used when I started web development. It was for a project built on Next.js and Supabase, and I wanted to implement some features that—in theory—should have been straightforward. Unfortunately as a beginner, I had such a hard time that I eventually moved onto Better Auth. Part of the issues I had could definitely be attributed to my inexperience, but also... the OAuth redirect flow had me screaming at my monitor.

Supabase Auth works well for many use cases, just maybe not mine at that time. But if you're doing anything beyond basic auth, be prepared to spend some quality time with their docs and maybe a few dates or debugging sessions.

Auth.js (Formerly NextAuth.js)

If you’ve built a Next.js app in the last few years, you’ve probably encountered Auth.js.

It’s open source, you own your data, no vendor lock-in. User data lives in your database and not on some third-party server. Auth.js supports 80+ OAuth providers out of the box, email magic links, credentials authentication, and has database adapters for Prisma, Drizzle, Supabase, and basically everything else. It's runtime-agnostic too, works with Docker, Node.js, serverless, etc.

But breaking news: Auth.js is now being maintained and overseen by the Better Auth team.

BetterAuth

It’s new, but promising (and I also have some fond memories with it). It's framework-agnostic, TypeScript-first, and positions itself as "the most comprehensive authentication library for TypeScript".

My frustration when working with Supabase Auth that I mentioned earlier—building the same auth primitives over and over, hitting limitations, wishing for other ways—is literally why Better Auth exists. The creator felt that auth in the TypeScript ecosystem was "a half-solved problem" where other libraries required tons of additional code for anything beyond basic auth. Rather than pushing third-party services, the goal was to build something the community could own.

And as mentioned earlier, Auth.js is now under BetterAuth’s team. The two biggest open-source authentication libraries in the TypeScript ecosystem are now working together rather than fragmenting. If you're using Auth.js today, you can continue doing so without disruption. The Better Auth team will keep addressing security patches and urgent issues as they come up . But—and this is important—they strongly recommend new projects start with Better Auth instead, unless you have very specific needs like stateless session management without a database.

Better Auth is free. And I mean, completely free. MIT licensed, no usage limits, no user caps, no features locked behind paid tiers. You can self-host everything on your own infrastructure with complete control over your user data and no recurring subscription fees. The project is backed by Y Combinator, but the core framework remains open source—they're building optional infrastructure services for scaling separately.

Better Auth's feature set solves exactly the problems I ran into with Supabase Auth. Multiple authentication methods work out of the box—email/password, social login with 50+ providers, magic links, passkeys. Two-factor authentication (TOTP, OTP) and organization and team management with role-based access control is built in. There's even built-in rate limiting and security features so you don't have to invent them from scratch. And it's genuinely framework-agnostic—React, Vue, Svelte, Next.js, Nuxt, Astro, Solid, Remix, Hono, vanilla JS—basically whatever stack you're reaching for, it works.

Better Auth also has a comprehensive plugin ecosystem meaning you don’t have to rebuild everything. Official plugins handle username authentication, email OTP, passkeys, admin controls, multi-tenancy, payment, more.

A quick full stop though: there’s a trade-off. Better Auth is newer so the ecosystem and community are smaller than Auth0 or even Auth.js historically. I remember facing issues with it too, since my very specific and odd edge cases don’t have exact answers on Stack Overflow.

If you're starting a new project today and you want to own your auth without paying per user or fighting limitations, Better Auth is probably where you should look first. The end goal—the one Auth.js had, the one Better Auth was built for—remains unchanged: you should own your auth.

To make it easier for you, here’s a quick summary table of the services I went over:

Service	Best For	Stack Fit	Setup Time	Key Strengths	Pricing (Free Tier)	Paid Starts At	Vendor Lock-In Risk
Clerk	Beginners, React/Next.js apps	React, Next.js, Remix	15 min	Pre-built components, 60-sec token refresh, passkeys	50,000 MAU	$20/month	High (fully managed, no self-host)
Auth0	Enterprise, compliance-heavy apps	Universal	4-8 hrs basic, 1-2 weeks complex	Feature-complete, Actions framework, enterprise SSO	25,000 MAU	$35/month (500 users)	Medium (standard OIDC, but migration pain)
Firebase Auth	Mobile apps, Google Cloud ecosystem	iOS, Android, Web	~15 min	Native mobile flows, well-documented, generous free tier	50,000 MAU	Pay-as-you-go after free tier	High (Google ecosystem lock-in)
AWS Cognito	AWS-native infrastructure	AWS services	1-2 days basic, 4-7 days prod	Tight AWS integration, identity pools for AWS credentials	10,000 MAU (Essentials tier)	Tiered (Essentials/Plus) + separate SMS/email costs	High (AWS ecosystem)
MojoAuth	Passwordless-first apps, WhatsApp-heavy regions	Universal	<15 min	WhatsApp verification, passwordless focus, competitive SMS alternative	25,000 MAU	$50/month (unlimited users)	Medium (newer, smaller ecosystem)
Supabase Auth	Open-source believers, PostgreSQL lovers	JS/TS, any framework	Varies	PostgreSQL-backed, self-hostable, queryable user data	50,000 MAU	$25/month	Low (open source, self-host option)
Auth.js	Next.js apps, data ownership purists	Next.js primarily, others supported	Varies	80+ OAuth providers, database adapters, no vendor lock-in	Free (open source)	Free (self-host)	None (you own the data)
Better Auth	TypeScript lovers, teams wanting self-hosted control	Any framework (TypeScript-first)	Varies	Comprehensive features (orgs, RBAC, rate limiting), plugin ecosystem, YC-backed	Free (MIT licensed)	Free (self-host)	None (open source, optional infra services)

So... which one should you pick?

If you've made it this far, you've earned the right to be overwhelmed. There are a lot of options, and I just threw eight of them at you (sorry hehe). But also, not sorry—because the right answer depends on you, and you deserved to see the full landscape before deciding.

Here's what I hope you take away from all my yapping:

Web development is a lot. And auth is just one aspect you have to mull over. But, this also doesn’t mean that it’s something you can overlook. It isn't something to half-ass. Your users entrust their data to you, and it’s up to you to make sure that you’re doing everything in your power to make sure that no bad actor can have access to that. It's the door to your entire application, and if that door is flimsy, nothing else matters. But building that door from scratch? Nope. It'll take longer than you think, cost more than you expect, distract you from whatever you actually wanted to build, and might result to a very flimsy door.

The services above exist so you can focus on your actual product. Use them.

If you're a solo dev building your first serious app, I say start with Clerk or Firebase. They're forgiving, well-documented, and let you see progress in minutes, not days.

If you're building inside someone else's ecosystem (like AWS or Google Cloud), use their auth. Fighting the platform is exhausting, and also why. Surrender to Cognito or Firebase Auth and move on.

If you're paranoid about vendor lock-in (hi, fellow paranoids), go open source. Supabase Auth if you want batteries included, Better Auth if you want TypeScript purity and plugin flexibility. You'll own your data, sleep better at night, and never get a surprise bill because one user authenticated too many times.

If you're building for enterprise and compliance is the whole conversation, Auth0 will check every box. Just budget extra time for setup and extra money for the inevitable overages.

And if you're going passwordless in a WhatsApp-heavy market, MojoAuth is doing something genuinely interesting. Worth a look.

The throughline in all of this? Understand your factors, protect data in motion and at rest, and never build auth yourself unless you're prepared to maintain it forever (if you have no commitment issues).

(It’s also good to note that there’s also the data in use, but that’s an article for another day)

Okay, that’s it. Go build something worth authenticating into.

DEV Community