Hritesh SonawaneSecurity engineering
NotesApplication securityModule 2

Module 2 of 5

Authentication

How an application decides who is making a request: stored credentials, sessions, delegated sign-in, tokens, and the second factors that resist phishing.

5 lessons95 min reading

Authentication turns a claim (“I am alice”) into something the application can rely on for the rest of a session. Each step of that process has its own failure: a password database that cracks in an afternoon, a session cookie that an attacker chose, an authorization code redeemed by the wrong app, a token verifier that trusts the token’s own header, a one-time code typed into a phishing page. The five lessons take those steps in order, from storing a password to replacing it with a passkey.

By the end of the module you should be able to review a sign-in flow and say which secret proves identity at each hop, where an attacker could capture or replay it, and which check, made by the server and not the client, stops them. Every lesson includes a small simulated attack and the fix, in Python you can run.

Lessons

  1. 2.aStoring credentialsHow should an application store passwords so that a stolen database is not a list of passwords?21 min
  2. 2.bSessions and cookiesHow does a server remember who you are between requests, and how do attackers steal, plant, or ride that memory?19 min
  3. 2.cOAuth and OpenID ConnectHow does "Sign in with..." work, and which checks stop a stolen authorization code or a forged redirect from becoming account takeover?19 min
  4. 2.dTokens and JWT pitfallsWhat can go wrong when a server verifies a JSON Web Token, and when should it use an opaque token instead?17 min
  5. 2.eMFA and passkeysWhich second factors actually stop phishing, why do passkeys succeed where one-time codes fail, and where does the attacker go next?19 min