Sign in with somebody else
What OAuth actually does, and why it is usually the safer choice.
"Sign in with Google" does not give your app the user’s Google password. It never touches your servers. Instead your app sends the user to Google, Google authenticates them and asks whether they consent, and then Google hands your app a token saying "this is a verified user, here is their email".
The upside is substantial. You never store a password, so you cannot leak one. Password resets, breach handling, and two-factor authentication become someone else’s full-time job. For a small team this is a real reduction in the amount of security you personally have to get right.
- You never see or store the password.
- Two-factor and breach detection come along for free.
- You now depend on that provider being available.
- Users without an account there need an alternative path.
What to remember
- OAuth delegates identity checking; you never receive the password.
- It removes a whole category of risk you would otherwise own.
- It is exactly the wrong thing to implement from scratch.
Terms in this lesson
Field notes
Loaded from a deliberately slow source. The lesson above was already readable while this was still travelling. That is streaming, and it is the same trick a chat interface uses.
The URL that read everyone’s invoices
An invoice page checked that you were logged in and then loaded whatever id was in the address. Changing the number showed somebody else’s invoice. It was found by a customer who mistyped, not by a review.
Classic IDOR, still extremely common
The key in the client bundle
An API key was placed behind the public environment prefix so it would be readable from the frontend. It worked. It was also visible to every visitor, and was being used by strangers within a week.
Scraped from a public bundle
resolved in 901ms · region iad1
Hide field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.