Before we get overwhelmed by the jargon, let's talk about the actual problem we are solving. At some point, every app needs to answer one question: is this person actually who they say they are? That is it. Authentication is just the collection of strategies engineers have invented to answer that reliably.
Think of it the way you would in the real world. You lock your house because you do not want intruders accessing your stuff. Authentication is exactly that, but for your digital resources.
Every method needs two ingredients: a unique identifier that picks you out from everyone else (a username, an email address, a phone number, a device) and a secret that proves that identifier genuinely belongs to you. Every method in this post is just a different answer to what those two ingredients should be.
Let's go through all of them.
1. Basic Authentication: Username and Password
The classic. You are given a unique username, and you set a password for it. The server saves that password, and when you come back to log in, the server verifies what you entered against what it has stored for your username. Alternatively, and more commonly these days, your email serves as the unique identifier instead of a username. Same idea, same flow.
Advantages: Easy to implement and set up. You can roll out your own auth for this without too much trouble, and you own the whole flow.
Disadvantages: It is too basic and can be bypassed relatively easily. The entire burden of proof is on the user. They are responsible for picking a strong password, not reusing it elsewhere, and not handing it over to a phishing page. Most people do at least one of those things wrong.
2. Basic Authentication with Two-Step Verification
This is a step up from the above. Here we verify the user twice before confirming what they are claiming to be.
- Email and password with a verification link: The user enters their email and password. Before we grant access, we send them a verification link. The user has to click that link before we let them through to their resources.
- Email and password with an OTP on email: The same flow as above, just instead of sending a verification link, we send a time-limited OTP. The user has to enter it before it expires.
- Phone number with password and OTP via SMS: Same flow as all the above, but this time the unique identifier is the phone number, and the OTP comes to the user's SMS inbox, verifying that they actually have access to that phone number.
Advantages: Still relatively easy to implement on your own. The user now needs to have physical access to the identity resource (their inbox or their phone) to verify themselves.
Disadvantages: Auth can be bypassed using burner emails or prepaid phone numbers, and this can be misused to access your resources without real accountability.
3. OIDC, or most famously known as OAuth: Let Someone Credible Vouch for You
OpenID Connect (OIDC) is an authentication protocol built on top of the OAuth 2.0 framework. It allows applications to securely verify a user's identity and retrieve basic profile information (like name and email) without forcing the user to manage and share passwords
Let me explain it in simple words. Here we use social providers to vouch for your identity.
Think of it like applying for a bank loan. The bank does not know you personally, so they ask for a guarantor: someone credible who can vouch that you will pay back what you owe. The guarantor's word stands in for the bank's direct knowledge of you. Critically, the guarantor has to be someone the bank already trusts.
If you have ever clicked "Sign in with Google," "Continue with Apple," or "Allow this app to access your GitHub," you have used OAuth.
Here is how the whole thing actually works:
First, you need credible guarantors. In our case, these are apps that have agreed to act as guarantors for the people coming to your app. Some famous examples are Google, Facebook, GitHub, Apple, and Microsoft. You go to these providers and ask them to be a guarantor for your users. For this, you register your app's URLs with the provider, and in return the provider gives you a client ID and a client secret. This is essentially authentication for your app itself, so that the provider can verify that the service redirecting users to its login page is actually yours and not someone impersonating you.
Now, when a user comes to your app and clicks "Sign in with Google," a process begins. Your app reaches out to the provider and says: "Someone wants to log in. Are you willing to vouch for them?" The provider then checks if it knows this person. If yes, it shows the user a screen that says: "I will act as a guarantor for you with this app. Would you like to continue?" The user clicks continue.
Under the hood, two things happen at this point. The provider sends a challenge, which the user completes at a redirect URI you defined during registration. If that is successful, the provider calls the /callback route you set up in your app and sends back a token. You use that token to fetch the user's details (name, email, profile picture), and then you save whatever you need and issue your own access tokens or sessions based on your auth strategy from there.
Advantages: No password to remember for every site. The guarantor handles identity verification. Also, it is easy for the user to try, since they already have an account with these providers.
Disadvantages: If the user loses access to their guarantor (locked out of Google, for instance), they lose access to everything they signed into through that provider. Your app knows users only through the intermediary, like a friend-of-a-friend situation, and cannot reach them directly if the connection breaks.
4. Passwordless Authentication: Magic Links
This one is for those who want to really test a user's patience. Personally, I get irritated every time I encounter this flow.
The idea is to remove passwords entirely. Every time a user wants to log in, you send them a code or a link to their registered email or phone. A link with the code embedded is more common, since it means the user does not have to manually type anything. They just click. Whoever opens that link is authenticated as that user.
The most important thing to understand here: if your magic link leaks, your account is compromised. The entire security model rests on that link staying private.
Advantages: The user has to have access to their identifier at all times. The moment they lose access to their inbox or phone is the moment they cannot log in, which means you know the person logging in actually controls that resource. Burner emails are much harder to exploit here because the attacker would also need access to the inbox, not just the address.
Disadvantages: User friction. They have to open their email, find the link, and click it every single time they want to log in. If you log in frequently, this gets old fast.
5. Passkeys: Your Device Is the Proof
Passkeys are the absolute best, if you ask me. The idea is that you yourself, or your device, serves as the identity. Think about how, on the internet, your identity is your IP address or your domain name. Passkeys do something similar: your device or your biometrics act as a unique identifier for verifying who you are.
How this works is genuinely fascinating if you understand even a little about encryption. So let us deviate from the main topic for a moment, because it is worth it.
Encryption, in simple terms, is hiding information in such a way that it cannot be read or decoded easily. A famous and very simple example is ROT13, where you rotate each character in the alphabet by 13 positions, a well-known problem in programming circles as well. That is symmetric encryption at its simplest: the same transformation both encodes and decodes.
Now, encryption is broadly of two types: symmetric and asymmetric.
Symmetric encryption is easy to picture. Think of a lock and a key. You have one key, and it can both lock and unlock the lock. Same key, both directions.
Asymmetric encryption changes this. You have a separate key to lock and a separate key to unlock. These are called the private key and the public key. As the names suggest, your private key should stay completely private. Never share it with anyone. Your public key can be shared freely with the world. This separation ensures that even if someone intercepts the public key in transit, they cannot do anything with it. They can only lock things with it. They cannot open what was locked.
Now let's come back to authentication.
In passkeys, your device acts as your private key. When you register a passkey with a service, your device generates a public/private key pair. The public key is sent to the server and stored there. The private key stays locked inside your device, stored in the Keychain on iOS and macOS, the Keystore on Android, or the TPM chip on Windows.
When you come back to log in, the server sends you a challenge: a piece of random data. You sign that challenge using your private key (unlocked by your biometric, either fingerprint or Face ID). The signed response goes back to the server, and the server verifies it using the public key it stored during registration. If the signature matches, your identity is confirmed.
No password. Nothing that can be phished or stolen in transit. Secure as long as you do not lose your device or compromise your biometrics.
Advantages: Highly secure. Extremely convenient for the user. One touch and they are in.
Disadvantages: Implementation is on the harder side compared to the other methods above.
6. Authenticator Apps (TOTP)
This is the next level of security. If you have ever tried making your Google account "extra secure," you would have noticed the option to use an authenticator app. What this does is generate a TOTP (Time-Based One-Time Password).
TOTP is an algorithm that generates a unique password for each login attempt, using time as one of its parameters. Here is the key detail most explanations miss: it does not use time alone. During setup, the server generates a shared secret (usually shown as a QR code that your authenticator app scans and stores). From that point forward, both your server and your authenticator app independently run the same mathematical algorithm, using the shared secret combined with the current timestamp divided into 30-second windows, and they arrive at the same six-digit number.
You enter that number, the server checks that it matches what it computed on its end, and you are in.
Because both sides compute the code locally using the shared secret, there is nothing travelling over the network to intercept. This is what makes TOTP meaningfully more secure than SMS OTPs. SIM-swapping attacks that can intercept SMS codes simply have no target here.
Works entirely offline, too. Your authenticator app does not need a cell signal or internet connection to generate the code.
Advantages: Highly secure. Resistant to interception and SIM-swapping. Works offline. Requires the attacker to have physical access to your device with the app installed.
Disadvantages: Requires the user to download a separate third-party app. If the user loses their phone and has not saved backup codes, they are effectively locked out.
7. SSO: The Enterprise Special
Imagine you run a company. For every new hire, that person has to create 50 separate accounts across every internal tool, then request that their account be added to the right team or group for each one so they can actually start working. Isn't that a massive headache? It would take several hours just to get set up on day one.
This is exactly where SSO, which stands for Single Sign-On, comes in. As the name suggests, you sign in only once. You log into the company's identity provider, and that single authentication gives you access to all the different software and teams you are supposed to have access to. No manual account creation, no requesting access to 50 different tools.
When someone leaves the company, an admin revokes their access in one place, and they are immediately locked out of everything simultaneously. Onboarding and offboarding that used to take hours now take minutes.
Advantages: Massive productivity boost for employees. Centralized control for IT admins. Clean, auditable access management.
Disadvantages: Complex and expensive to set up correctly. If the SSO provider goes down, nobody can log into anything. It is a deliberate single point of failure, which is why IdP providers invest heavily in availability.
The Real Engineering Part
Every method above is trading off three things: security, user experience, and implementation complexity. No single method wins on all three, and the right choice depends entirely on your actual threat model.
Basic auth is the fastest to ship but leaves the most attack surface. OAuth hands identity to a trusted third party, good for both security and UX, but you now have a dependency you do not control. Passkeys are the most secure and the most frictionless once set up, but carry the largest implementation surface. TOTP occupies a useful middle ground for high-security flows without external dependencies.
The question most engineers skip: what are you actually defending against? A personal notes app does not need passkeys. A payment flow that skips two-factor authentication is negligent.
In most production systems, you do not pick one method. You layer them. OAuth for initial sign-in, TOTP as a second factor for sensitive operations, short-lived sessions throughout, SSO if you are building internal tooling. The combinations matter more than any individual choice.
The Catch
A few things that do not fit neatly into the comparison above but matter when you actually build this.
OAuth token storage is where most implementations go wrong first. Access tokens in localStorage are readable by any JavaScript on the page, including third-party scripts. Prefer httpOnly cookies or hold tokens in memory only. Short-lived access tokens with refresh token rotation are not optional in production; they are the baseline.
Magic link integrity has two non-negotiable rules: the token must be single-use (invalidated immediately after the first click), and it must expire even if it is never clicked. Skip either of these, and you are not implementing magic links. You are implementing persistent session tokens that happen to arrive by email.
TOTP clock drift is a real support ticket waiting to happen. The standard allows a one-window tolerance: the server checks the previous and next 30-second window alongside the current one, but a device with a significantly drifted clock will fail consistently. Always return a useful, specific error message rather than a generic "invalid code."
In the next post, we will get into the actual implementation: code for handling sessions, issuing JWTs, setting up OAuth with a provider, and wiring up TOTP from scratch. If the theory clicks here, the code will make it permanent.
Happy Exploration!
Top comments (0)