Skip to content

Authentication, sessions, and JWT

Authentication، sessions اور JWT

42 min read

Three ways to see it

  1. Authentication answers 'who are you?'. Authorization answers 'what are you allowed to do?'. Both are needed. The flow has three stages: first, the user proves identity (password, OTP, biometric, OAuth from Google or NADRA Pak-ID). Second, the server issues a credential (a session id stored in a cookie, or a JWT signed token). Third, every later request carries that credential and the server checks it. Get any of these three stages wrong and you ship a vulnerability. In 2026 OWASP Top 10 still lists broken auth as the second most common critical bug.

  2. Way one, passwords done right. Never store passwords in plain text. Use a password hashing algorithm designed for it: bcrypt or argon2id. On signup: const hash = await argon2.hash(password). On login: const ok = await argon2.verify(stored, attempt). Modern guidance from NIST and SBP: minimum 12 characters, no forced rotation, allow paste, support password managers, do not impose stupid complexity rules. Add rate-limiting on login attempts (5 per minute per IP and per account). Always send password reset links over email or SMS, never the password itself.

  3. Way two, sessions versus JWT. After login, you must give the user a credential. Two main styles. Session cookies: server stores a random session id in a database or Redis, the user's browser holds a cookie with that id, every request includes the cookie, the server looks it up. Simple, revocable (delete the row, the user is logged out), and the default in classical web apps. JWT: server signs a JSON token containing user info and an expiry, the user holds the token, the server verifies the signature without a database lookup. Faster, stateless, but harder to revoke. For most Pakistani fintech, cookies with a short-lived JWT inside is the sweet spot: server-side revocation plus client-side performance.

Quick check

Quick check: what makes modern AI different from a rule-based program?

The why-tree

Why-tree level one: why hash passwords? Because databases get leaked. The 2021 leaks of Pakistani e-commerce and salary platforms showed that. Hashed passwords are useless to an attacker without billions of dollars of compute. Plain-text passwords are gold. The cost of hashing is microseconds; the cost of skipping it is your company on a news ticker.

Try this with Claude

AI-edge prompt to try with Claude: 'Walk me through implementing OAuth 2.0 sign-in with NADRA Pak-ID (assume their endpoints are at id.nadra.gov.pk/oauth/authorize and id.nadra.gov.pk/oauth/token). Include CSRF protection with state parameter, PKCE, secure cookie setup, refresh-token rotation, and a logout flow. Code in Hono + Drizzle. Cite RFC 6749 sections for each decision.' Read every line before you trust it.

Sources

Sources and further reading. OWASP Authentication Cheat Sheet (cheatsheetseries.owasp.org). NIST SP 800-63B digital identity guidelines. RFC 6749 OAuth 2.0 and RFC 7519 JWT. RFC 7636 PKCE. argon2 reference (github.com/P-H-C/phc-winner-argon2). Auth0 and Lucia auth library docs. SBP Open Banking Identity working group drafts. NADRA Pak-ID developer brief. PECA 2016 sections on credential theft.