The Problem with Passwords

Passwords work, but they have costs

If you have built password-based authentication before (or completed the “Authentication with Hectoday HTTP” course), you know the basics: the user picks a password, you hash it with bcrypt, and you verify it on login.

That works. But it comes with baggage.

The user’s problem: too many passwords

The average person has accounts on dozens of services. Each one wants a unique, strong password. Nobody actually does this. People reuse passwords, pick weak ones, or rely on a password manager (which most people do not use).

Every signup form that asks for a new password is friction. Some users abandon the process entirely. “Do I really need another account for this?” Others sign up with a throwaway password they will forget, then hit “reset password” every time they come back.

Social login removes this friction. The user clicks “Log in with GitHub,” confirms on a page they already trust, and they are in. No new password to invent, remember, or manage.

Your problem: you hold the passwords

When you store password hashes, you become a target. Even with bcrypt, your database is valuable to attackers. A breach exposes email addresses and hashes. You have to notify users, deal with the fallout, and hope your hashing was strong enough.

With social login, you never see the user’s password. GitHub (or Google, or whatever provider you use) handles credential verification. You store a GitHub user ID and a session, but no password hash. If your database is breached, there are no credentials to crack.

You are delegating the hard part (password storage, brute-force protection, two-factor auth) to a company that invests heavily in security infrastructure.

What social login looks like

From the user’s perspective:

1. They click “Log in with GitHub” on your site
2. They are redirected to GitHub
3. GitHub asks: “Do you want to let this app access your profile?”
4. They click “Authorize”
5. They are redirected back to your site, logged in

From your server’s perspective:

1. You redirect the user to GitHub with some parameters
2. GitHub authenticates the user (their password, their 2FA, their session)
3. GitHub redirects the user back to your site with a short-lived code
4. Your server exchanges that code for an access token
5. Your server uses the access token to fetch the user’s profile from GitHub’s API
6. You create or find a local user account and start a session

The protocol that makes this work is called OAuth 2.0. It defines the redirects, the parameters, and the token exchange. In the next lesson, we will walk through it in plain language.

What this course covers

You will build OAuth-based login from scratch using plain HTTP calls. No authentication libraries, no Passport.js, no Auth0 SDK. Just the actual HTTP requests that the OAuth protocol defines, built on Hectoday HTTP.

By the end, you will have:

• GitHub login (the primary provider)
• Google login (a second provider showing how the pattern repeats)
• Account linking (one user, multiple providers)
• Error handling for every failure mode
• The option to combine OAuth with traditional password auth

Everything is plain functions and standard fetch calls. You will understand what authentication libraries do internally, which puts you in a position to use them wisely or replace them when they do not fit.