DEV Community: Precious Mae

Back to Basics: A Developer’s Guide to Authentication

Precious Mae — Sun, 01 Mar 2026 12:50:31 +0000

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.

Security with AWS Cognito: Building Your First User Pool

Precious Mae — Mon, 04 Nov 2024 06:42:35 +0000

One of the most important features of any application is user authentication. It's also almost always the first feature you create when building an application. Yes, you could go about building your authentication and authorization for your web app, but building a secure authentication service is complex and time-consuming and exposes your app and your users to unnecessary risks.

This is where 3rd-party authentication services come in. It provides secure authentication, scalability, and a positive user experience. So many services are on the market right now, but we will focus on Amazon Cognito and see what it has to offer.

But before all that, why choose Amazon Cognito?

Amazon Cognito is an excellent and secure way into user authentication for web and mobile applications, especially when you're already heavy in the AWS ecosystem, since it interacts well not only with API Gateway but also with IAM. Additionally, Cognito is an AWS managed service, so you do not have to worry about your infrastructure or security maintenance, and it scales automatically to handle your growing user base. In terms of pricing, on the other end, for levels of low to medium users, Cognito offers a free tier. If you are just getting started, that would probably be perfect for you.

What is Amazon Cognito?

Amazon Cognito is the identity platform for web and mobile apps. It's a user directory, an authentication server, and an authorization service for OAuth 2.0 access tokens and AWS credentials. It represents a secure, scalable, and customizable authentication service with easy integration of other AWS services. Let Cognito do the heavy lifting for authentication and authorization, freeing you up to build the important parts of your application.

Amazon Cognito is composed of building blocks such as User Pools and Identity Pools.

An Amazon Cognito user pool is a completely managed user directory through which authentication and authorization of users to either web or mobile applications is made quite easy. It stores user information in a secured manner, manages user signup and sign-in, and resets passwords. In addition, it supports MFA and social identity provider integration, which enhances security and improves user experience. Conversely, with Cognito User Pools, one would be offloading some complexity in user management and focusing on core features of the application.

On the other hand, the Amazon Cognito Identity Pool is a service that provides easy and secured authentication and authorization into web or mobile applications. It allows for user identity management temporary AWS credentials and provides for flexible access control to AWS resources. Users can use your application without an account or log in with their social identities via Google, Facebook, Amazon, or Apple. With Cognito, you handle users efficiently and add an extra layer of security, so you can focus on the core features of your app.

Creating your first user pool

Note: This tutorial is intended for beginners, as such we’ll be utilizing the AWS Console instead of the CLI. Additionally, I am expecting that you already have your AWS Account ready for use.

Of course, Cognito also allows for use with other frameworks and technologies such as React and Flutter. But aside from the these, Amazon Cognito also boasts a Hosted UI Service. This hosted UI service is a pre-built user interface provided by Amazon Cognito to handle user authentication and authorization tasks. We will use this feature to test out the Cognito service for the first time.

Go to your AWS Console, and look for Cognito.
Click on Create User Pool.

On Step 1, ensure that for authentication providers Cognito User Pool is selected. Also, click on Username and email for the sign-in options.

In Step 2, ensure that Cognito defaults are chosen for the password policy. For MFA, choose Optional MFA, and allow for Authenticator apps and SMS. Also enable self-service account recovery, with email only chosen.

For Step 3, keep everything as default.
Enable self-registration, and allow Cognito to automatically send messages to verify and confirm. For attributes to verify, choose Send email message, and verify email address. For verifying attribute changes, ensure that Keep original attribute value active when an update is pending is checked. For required attributes, ensure that email is chosen by default.
For Step 4, pick Send email with Cognito. This is appropriate since we are just testing out the features, but Amazon SES is recommended for use for enterprise-level workloads.
For SMS messages, Create a new IAM Role, and name it CognitoSMS or whatever you prefer.

For Step 5, configure a pool name, you can name it MyFirstUserPool or whatever you prefer. Afterwards, click on Use Cognito Hosted UI. Then, configure a Cognito domain that you would like to use.

For the app client, ensure that the Public client is chosen. For the client name, you can choose the same name for your pool name, or something else. Click on Do not generate client secret. For your callback URL, use https://[your domain name].auth.us-west-2.amazoncognito.com/auth-callback (This won't work since we do not have an application, and the information goes nowhere. We're just using this as a placeholder so Cognito allows us to create the user pool.

Lastly, review your choices and click on Create user pool.

Once your User pool has been created, you can click on it and navigate to App integration. Once you're there, scroll down to your App clients and click on your App client. Navigate to the Hosted UI segment and click on View Hosted UI.

Populating your user pool

Once in your Hosted UI, click Sign Up and fill out your email, username, and password.

Cognito will send you a verification code in your email, look for it and enter it on the verification page.

Once verified, it will redirect you to the callback URL (which, as mentioned earlier won't do anything).
Go back to your Cognito console, and click on your user pool.
Check the user's tab, and look at the user that you signed up earlier.

Note: Signing in will not give any response, as we didn't handle our callbacks properly.

Congrats! You just made your first Amazon Cognito user pool using it's Hosted UI service.

This walkthrough introduced you to Amazon Cognito's user pools and hosted UI service, which is just the beginning of your journey through the Amazon cloud. While this tutorial focused on manual configuration in the console, like with many AWS services, Cognito also covers SDKs and integrations with other frameworks, such as React and Flutter. For more information, you can refer to the official documentation here.

Back to Basics: Git and GitHub Crash Course

Precious Mae — Tue, 27 Aug 2024 03:16:02 +0000

Edited (11/04/2024): Included git switch command.

One of the most important concepts you have to learn when starting out in coding, and one you’ll continue to use even as you become a professional, is Git and GitHub. With these two technologies, you’ll be able to streamline your coding workflow, collaborate seamlessly with teams, and contribute to open-source projects.

Note: This article is intended for ultimate beginners to begin using Git bash. Git has multiple GUI clients that could be used, including GitHub desktop, but we'll be using Git bash in this article.

Git vs GitHub

Contrary to most beginners’ belief, Git and GitHub are entirely different from one another. However, they are commonly used alongside one another.

Git is the most famous and widely used free and open-source version control system. It's used by most industry tech companies such as Google, Twitter, Microsoft, and many more. It was created by Linus Torvalds, the creator and lead developer of the Linux kernel, in 2005.

GitHub, on the other hand, is a repository hosting service. It is a place for developers to publish their code. When working on a team, you often need a remote place to put your code so others can view or access it, and even contribute to its development.

Your GitHub Account

To start, let's create your GitHub account first.

Navigate to GitHub, and click on Sign up on the right of the header.
Enter your email address, a password, and a username.
GitHub will send a verification to code to your email address, access it and enter it when prompted.

Starting out with Git

As mentioned earlier, Git is a free and open-source version control system. Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Your First Repo:

First, navigate to the Git downloads page.
Download the latest 64-bit version of Git for Windows, and install it once it has finished downloading.
Open Git Bash by navigating to the folder where you have installed the Git or just simply search in the Windows search bar for Git bash.
Run the following command to Git bash: git --version. If Git was installed properly, it should show the version of Git you just installed.
Now let's let Git know who we are and setup your username and email.
Run the following commands:
```
git config --global user.name "yourusername"
git config --global user.email "your@email.com"
```
Note: Use the same credentials you used with your GitHub account in the prior section.

Check if everything is configured correctly:
```
git config --global -l
```
Set up your default code editor. For this article, we'll be setting VSCode as our default:
```
git config --global core.editor "code --wait"
```

Remote repository

Now, let's create your first remote repository.

Create a folder using the command:
```
mkdir first-repo && cd first-repo && code .
```
Note: mkdir stands for make directory, it creates a folder with the name you specified, in this case, it is first-repo. cd stands for change directory, it changes your current working directory. code . opens your current directory in your chosen code editor.
Initialize your first Git repository.
```
git init
```
Create your first file in the repository.
```
touch HelloWorld.c && code HelloWorld.c
```
Note: touch is a standard command used in the UNIX/Linux operating system which is used to create, change and modify the timestamps of a file, in this case we are using it to create the HelloWorld.c file. code HelloWorld.c is a VSCode command that opens the file specified, HelloWorld.c in VSCode.

Paste the following code to the file:

   #include <stdio.h>

   int main(){
            printf("Hello World!");
   }

Save your changes and run this command in the terminal:
```
git add .
```
git add tells Git to begin tracking the files specified. the . adds all the files in the current directory you are in.

Before changes are committed to the repository history, they live in the staging index and the working directory.

The contents of your project folder (the folders and files you find within it) are represented by the working directory. The staging index is when Git starts tracking and saving changes that occur in files. Files in the staging index are tracked by Git.

If you don't want to track all the files in your directory, you can manually list the files you wish to track, e.g. git add Documentation/*.txt, which adds content from all *.txt files under Documentation directory and its subdirectories, or git add README.md HelloWorld.c, which adds the README.md file and HelloWorld.c file.

Files in your Git repository folder can be in one of 2 states:

Tracked - files that Git knows about and are added to the repository.
Untracked - files that are in your working directory, but not added to the repository.

Commits

Check if the status of your repo using:
```
  git status
```
This will display your tracked and untracked files, the status of your branch (if it is ahead or behind), etc.
Since all your changes have been staged, you are ready to create your first commit.
```
git commit -m "chore: init"
```
Note: git commit is the command to create a commit. -m is a subcommand used to specify a commit message, in this case it is the "chore: init". If you don't use the -m subcommand to specify a message, Git will open your code editor to make you write a commit message.

Commits act like snapshots of your repository at specific times. You should make new commits often, based around logical units of change in your code and repository. Commits include lots of metadata in addition to the contents and message, like the author, timestamp, and more.

Commits require a commit message. These messages are extremely important, as they become a descriptor for the change you are commiting. To know how to write proper commit messages, check out this link: Guide for conventional commits.

Branches

Let's say I want to create another version of my project without affecting the main one. We can use branches to do this. Git branches are like separate paths or versions of your project where you can work on different features or fixes without affecting the main project. For local repositories, the name of the main branch is called master, while on GitHub it is main.

Create a new branch:
```
git branch name
```
name is the name of the new branch we want to create, you can use whatever name you want, but in this tutorial let's use name. If Git finds a branch with a similar name, it will throw an error.
Change from your current branch to your new branch.
```
git checkout name
```
You can actually combine the these two steps into one by using:
```
git checkout -b name
```
This will create a new branch named name and also change your current branch to name.

You can also use a git switch to create a new branch and switch to it.
```
git switch -c name
```

Check what current branch you are working on with

git branch

If you are working on the correct branch, paste the following code into your HelloWorld.c file.

   #include <stdio.h>

   int main(){
            char name[] = "Linus";
            printf("Hello, %s!", name);
   }

Stage and commit your changes:

git add .
git commit -m "feat: added a variable name to print"

Now checkout your main branch with:
```
git checkout master
```
If everything worked out, this branch should not include the changes you made in the name branch.
Let's merge the two branches together. Before merging to master, make sure that everything works first to ensure that you don't break anything.

Assuming you are still in the master branch, run the command:
```
git merge name
```
This command should merge your name branch into the master branch.

Local repository to Remote

Now, let's connect your local repository to GitHub.

Open GitHub and create a new repository. Add a repository name, in this case we'll use first-repo. Choose if you want to make this repository public or private, and if you want to initialize a README.md (but we'll skip this for now). Click on Create repository once you're done.
After creating your repository, GitHub will redirect you to a quick setup page. Copy the https link provided.
On your first-repo directory, run the following commands:
```
git remote add origin <link you copied>
```
Replace the text inside the <> with the link you copied, and remove the <>. To see the remote repositories associated with your local repository, run:
```
git remote -v
```
Rename your branch
```
git branch -M main
```
This command will rename your current branch to main. The -m stands for 'move' or 'rename'. As mentioned earlier, local repositories use the name master for their main branch, while GitHub uses main.
Push all your local commits to GitHub.
```
git push -u origin main
```
git push is a command used to upload your local branch's commits to your remote GitHub repository. -u or --set-upstream is used to set the upstream branch, connecting your local main branch to the remote repository's main branch. You can just use git push after setting this. origin is the default name for the remote repository in Git. main specifies the branch you want to push, in this case, the main branch.

This command should push all your local commits to your GitHub repository. Check your GitHub for the changes.

Pulling changes from remote to local

Now, let's say that you're working on a project with multiple people, and one of your team members just pushed a change to your main branch.

First, let's simulate how this work. Go to your GitHub repository and click on Add file and Create a new file. Name your file README.md, a README file contains information about your project.

A README.md uses Markdown Language. You can refer to this link for its' syntax: Markdown Language Syntax. Paste the following contents to your file:
```
# My First Repo

Local repository to remote.
```
You can preview its contents, by clicking on the Preview button next to the Edit. Once everything is ok, click on Commit changes. A pop-up will appear prompting a commit message. Click on Commit changes once you are done.
On Git bash, run the following command:

Since you already set the upstream branch earlier, you can just use git pull directly.
```
git pull
```
This will pull all the changes from your remote repository to your local. Look at your explorer or use the command ls in your Git bash to list all your files and directories. README.md should be listed.

Undoing changes

Let's say I want to undo my changes and go back to a certain version of my project. There are several ways to undo commits, like git revert, git reset, git checkout etc.

See all your commits using the git log --oneline command. This will display all the commits with their hashes. Commit histories are long, so the --oneline subcommand limits the information displayed to one line.
Copy the hash of the commit you want to go to. In this case, I want to revert to the initial commit with the hash a894e0f. But first, let's visit that commit.
```
git checkout a894e0f
```

Undoing a commit with `git checkout`

Checkout to the commit you want to go back to.
```
git checkout a894e0f
```
Using this command will remove you from your current branch, which means you won't be working on any branch.
From this state, we can run:
```
git checkout -b newbranch_nocommit
```
The repository is now in a timeline where the a894e0f commit no longer exists.

Undoing a commit with `git revert`

Git revert is used to record some new commits to reverse the effect of some earlier commits. Unlike git checkout, it creates a history of its undo. This is the ideal 'undo' method for working with public shared repositories.

Let's say I want to go back to my past commit.

    git revert HEAD

HEAD is your current branch, or active branch. Git can only checkout one branch at a time, and this is your HEAD branch. When you change branches using the checkout command, this new branch now becomes your new HEAD. git revert HEAD creates a new commit that undoes the changes made by the latest commit (the one pointed to by HEAD).

    git revert HEAD~3

This will revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.

    git revert a894e0f --no-edit

git revert a894e0f reverts to the commit with the specified hash. --no-edit skips the commit message editor, resulting in getting the default revert message.

Reverting to a certain commit will sometimes result in merge conflicts, wherein your past commit will have conflicts with your current commit. To handle these errors, you can open the conflicted file and decide what changes you want to accept.

Once you resolved all conflicts, run git revert --continue.

Undoing uncommited changes

In the case wherein you have only staged your files, but did not commit them yet, you can run:

git reset

git reset should generally be considered a 'local' undo method. git reset a894e0f can also be used, where a894e0f is the commit hash of the commit you want to go back to, but doing this will rewrite your repository's history, so it is not recommended. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers.

On the hand, when your changes are in the working directory, you can run:

git clean

This command removes untracked files from the working tree. The Working Tree is the area where you are currently working, or where your files live. It cleans it by recursively removing files that are not under version control, starting from the current directory.

From remote to local: Cloning

We created a repository by using git init in the prior section, but there is another way to create a repository, and that is by first creating a remote repository and cloning it into your local machine. This is helpful when you want to work on a project that is owned by someone else.

Similar to when we created a remote repository earlier, go to your GitHub, and create a new repository. Name your repository as second-repo, and initialize a README.md. Write in your README.md:
```
 # second-repo

 Remote to local.
```
Commit your changes.
Go to your repository's home page, and click on Code. Copy the HTTPS url.
In Git bash, cd to a directory you want to clone your repository into.
```
 cd repo-test
```
Once you're in the directory you want, run the command:
```
 git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
```
This will clone your remote repository to your local machine.
cd into your second-repo and open your README.md file. Edit the contents of your file:
```
 # second-repo

 Remote to local.

 This is an edit.
```

Save, stage, and commit your changes.

 git add README.md
 git commit -m "docs: edited README.md"

You can directly push to your remote repository.
```
git push
```

Conclusion

Git hosts a lot of features and commands, and what I covered in this article will only scratch the surface, but hopefully it will help you get started in exploring Git and GitHub. To know more, you can refer to Git's Documentation.

After reading article, you can consult W3School's Git and GitHub Tutorial or GeeksforGeeks' Ultimate Guide to Git and GitHub to explore other features such as .gitignore or pull requests.

The AI Tech Revolution: Will AI be replacing programmers?

Precious Mae — Mon, 19 Feb 2024 15:06:39 +0000

This article was co-authored by @angelakimmasong

In today's era dominated by the widespread influence of AI, its rapid transformation affects every sector across the country. Whether it’s healthcare or finance, AI’s rise has reshaped how things work, pushing industries into new frontiers of innovation. However, amidst this revolution, one area is surprisingly vulnerable: the world of technology itself.

As AI continues its relentless advancement, its impact on the tech industry is profound, challenging established norms while sparkling both awe and apprehension. One significant aspect of this transformation lies in the integration of AI into programming. This integration is poised to reshape programmer roles, automating repetitive tasks and allowing them to focus on higher-value work.

In this article, we’ll delve into the relationship between AI and technology, exploring the myriad ways of AI’s rise in reshaping how we innovate in the tech world.

How is the rapid growth of AI impacting the prevalence of layoffs in the tech industry?

In recent years, the tech industry has experienced significant shifts, with the rise of artificial intelligence (AI) playing a central role. According to Tech Crunch (2024), the tech industry has experienced 240,000 jobs in 2023, and has experienced around 20,000 layoffs in January 2024 alone. These alarming numbers are enough reason to concern tech professionals and beginners alike. The demand for AI became the driving force behind job cuts last year and continues to be a significant factor this year (Forbes, 2023).

Among these AI technologies is the rise of different code-generation technologies that bring uncertainties in the stability in the field.

Most popular AI code-generator technologies

Artificial Intelligence has transformed software development, leading to the rise in popularity of code-generation technologies within the tech industry. Here, are some of the most well-known AI code-generation tools that in recent years:

Blackbox AI:

Blackbox AI is a cutting-edge code generation technology that utilizes deep learning algorithms to automate the process of writing code. It is a sophisticated artificial intelligence model designed specifically for code generation. At its core, it excels in understanding natural language requests and translating them into functional programming constructs (Blackbox AI Code Chat, 2024).

GitHub Co-pilot:

Developed by GitHub in collaboration with OpenAI, GitHub Co-pilot is also a powerful code completion tool that assists developers in writing code more efficiently. It suggests code snippets, identifies relevant APIs, and provides real-time feedback as developers write code.

It contributes to solving selected fundamental problems in computer science, such as sorting and implementing data structures, and generates a dataset of programming problems with human-provided solutions (GitHub Copilot AI Pair Programmer: Asset or Liability?, 2023). Furthermore, it has gained significant traction among developers and organizations, with notable improvements in code quality and productivity reported by users (GitHub: AI Helps Developers Write Safer Code, but You Need to Get the Basics Right, 2023).

ChatGPT:

This platform has gained a lot of popularity and is a versatile AI model developed by OpenAI that can generate code based on user input and context. The technology has numerous applications in various industries, including customer service, education, healthcare, and entertainment.

The limitations of AI

Though we are seeing rapid advancements in technology, there is one fact about AI that cannot be ignored: Artificial intelligence can’t think on its own. Currently, the AI we know today relies on machine learning, which lets computers learn by experience by feeding it massive amounts of data that it then processes. These machines are categorized as weak AI, meaning they are only programmed to do one specific task. Ultimately, we are still far from creating Artificial General Intelligence, which would be capable of exhibiting the full range of human capabilities, including creativity (Lifewire, 2023). All this just means one thing, and that is that the AI we know today still lacks the ability to fully be independent and still relies heavily on human engagement.

Although code-generation technologies exist, they cannot fully replicate the human mind. The act of programming requires human creativity, intuition, and judgment, which are yet to be replicated by artificial intelligence. It is up to humans to ideate and create complex systems to solve different problems and make important decisions. These code-generation technologies only serve as a supplement, letting the machines do the mundane and small tasks to let the professionals focus on the more meaningful work.

Conclusion

The introduction of AI technologies is reshaping the way different industries work, including the tech industry. One of these ways is how it introduced different code-generation technologies that offer valuable assistance to programmers. However, due to its inability to fully replicate human thought and abilities, these technologies still fall short of fully replacing humans in the field. While the recent developments in artificial intelligence are impressive, its limitations leave it to remain a complementary tool that is still incapable of replacing human ingenuity in the field of programming.

DEV Community: Precious Mae

Back to Basics: A Developer’s Guide to Authentication

Table of Contents

Why should we care?

Why bother with the basics?

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

Protecting your data at rest

Encryption – Two‑Way, with Keys

Hashing – One‑Way, No Keys

How do we authenticate?

Something you have

Token-based authentication

One-time passwords (OTPs)

Push notifications

Something you are

Biometric authentication

Multi-factor authentication: Layering your defenses

All together now

Common Authentication Services: From Factors to Platforms

OAuth and OpenID connect

Passkeys, passkeys, passkeys.

Have you heard about vendor lock-in?

Clerk

Auth0

Firebase Authentication

AWS Cognito

MojoAuth

Supabase Auth

Auth.js (Formerly NextAuth.js)

BetterAuth

So... which one should you pick?

Further Reading & References

Security with AWS Cognito: Building Your First User Pool

But before all that, why choose Amazon Cognito?

What is Amazon Cognito?

Creating your first user pool

Populating your user pool

Back to Basics: Git and GitHub Crash Course

Git vs GitHub

Your GitHub Account

Starting out with Git

Your First Repo:

Remote repository

Commits

Branches

Local repository to Remote

Pulling changes from remote to local

Undoing changes

Undoing a commit with git checkout

Undoing a commit with git revert

Undoing uncommited changes

From remote to local: Cloning

Conclusion

The AI Tech Revolution: Will AI be replacing programmers?

This article was co-authored by @angelakimmasong

How is the rapid growth of AI impacting the prevalence of layoffs in the tech industry?

Most popular AI code-generator technologies

The limitations of AI

Conclusion

Undoing a commit with `git checkout`

Undoing a commit with `git revert`