OAuth and the Security Checklist

OAuth: "Log in with Google", demystified

Sometimes you do not want passwords at all. OAuth lets users prove their identity through an account they already have (Google, GitHub). The flow, simplified:

1. Your app redirects the user to the provider: "this app would like to know who you are".
2. The user consents on the provider's site. Their password is typed there, never on yours.
3. The provider redirects back to your app with a one-time code.
4. Your server exchanges that code (plus its own client secret) directly with the provider for a token, and reads the user's identity from it.
5. From here you are back in known territory: create the user row, start a session or issue your own JWT (lessons 7-2 and 7-3).

The key mental model: OAuth outsources the proving who you are step to someone users already trust, and hands your server a verifiable result.

The checklist

Authentication mistakes are the expensive kind. Before shipping any login system:

• Never roll your own crypto. Lessons 7-1 and 7-3 taught the mechanics so you understand them, production uses bcrypt/argon2 and a maintained JWT library (jsonwebtoken, jose).
• Hash passwords with bcrypt or argon2, salted, never plain, never SHA-256 alone.
• HTTPS everywhere. HTTPS is simply HTTP carried over TLS, the encryption layer from the quiz above. Tokens and cookies sent over plain HTTP are readable by anyone on the network path: coffee-shop wifi, a compromised router, your ISP.
• Cookies: httpOnly + secure, so page scripts cannot read them (the httpOnly flag from lesson 7-2) and the browser refuses to send them over plain HTTP (secure).
• Rate limit login attempts (unit 8), or attackers guess passwords all day.
• Keep error messages generic: "invalid email or password", never "wrong password", which confirms the email exists and hands attackers a user list.
• Secrets live in environment variables, never hardcoded in source files. Your code is tracked by git, the standard version-control tool that permanently records every past version of every file, and is usually pushed to GitHub, a site that hosts git projects for a team or the public. A secret committed once is therefore readable by anyone who ever gets access to the project, even after you delete it, because the history keeps it. Unit 8 starts exactly there.