Skip to content

session-plan.md

Latest commit

 

History

History
158 lines (109 loc) · 7.48 KB

session-plan.md

File metadata and controls

158 lines (109 loc) · 7.48 KB
Raw

Session plan

Session outline

  • Secure passwords & basic login using the Snippets API (≈40 min)
  • Stateless auth with JWT on the Snippets API (≈40 min)
  • Session-based auth on the Snippets API (≈40 min)
  • Third-party auth explained (5 mins)
  • Comparison of auth methods, brief look at DB tokens & API keys, and wrap-up (≈30–35 min)

Session materials

Examples for the code snippets present in the module materials examples can be run with this Postman collection. Make sure to have it downloaded an up and running.

Secure passwords & basic login (Snippets API)

Goal: Implement secure password storage and a basic login flow for the Snippets API using bcrypt.

  • Concept: why plaintext passwords are insecure.
  • Introduce hashing and salting with bcrypt.
  • Walk through the happy path for /login:
    • Look up user by username/email.
    • Compare plaintext password with stored hash using bcrypt.

Implementation of encrypted password login

See Secure passwords and basic login for a more detailed walkthrough.

Exercise 1 (15–20 min)

  • Add at least one user to the users table with a hashed password. You can use token column.
  • Implement /login using bcrypt in your own copy of the Snippets API.
  • Use Postman to test successful and failing login attempts.

Why is this approach insecure (5–10 min)

  • TODO: show how to break this
  • Discuss common mistakes (e.g. sending too much error detail, forgetting to hash passwords).

Stateless auth with JWT

Goal: Learn stateless auth with JWT on top of the secure login flow, and protect key Snippets API endpoints.

  • Concept: self-contained tokens with claims; no DB lookup needed per request.
  • Trade-offs: fast and scalable, but harder to revoke.
  • Show the high-level flow:
    • After successful bcrypt-based login, issue a JWT.
    • Client includes the token in the Authorization header.
    • Middleware verifies the token and attaches user info to req.user.

Implementation of JWT token in middleware

See Stateless authentication with JWT for detailed steps and examples.

Exercise 2 (15–20 min)

  • Protect at least two Snippets API endpoints (e.g. POST /api/snippets, DELETE /api/snippets/:id) using JWT middleware.
  • Add token expiration and handle expired tokens gracefully in responses.
  • Try to tamper with the token payload and see what happens.

Using JWT in Postman

  • Run through a full Postman flow together.
  • In Postman, add JWT as Bearer Token (unique token after login) or just JWT auth based on secret. Show the difference between authorised & authenticated reponse.

Session-based authentication

Goal: Implement session-based authentication using cookies and compare it to JWT for the Snippets API.

  • Concept: server-side sessions, session IDs in cookies, and typical use cases.
  • Contrast with JWT: stateful vs stateless, revocation, and infrastructure needs.

Implementation of session based auth

See Session-based authentication for detailed guidance.

Exercise 3 (15–20 min)

  • Protect at least one Snippets API route using session-based middleware.
  • Implement logout and verify that access is denied after logging out.

How are sessions different than JWT (5–10 min)

  • Compare the experience of working with sessions vs JWT.
  • Discuss scaling concerns (sticky sessions, shared stores) at a high level.

Third-party authentication (Firebase, Supabase, Auth0, etc.)

Goal: Understand what managed authentication providers are, what problems they solve, and how they relate to the methods used in this session.

  • Explain what third-party auth providers are:
    • Hosted “auth as a service” platforms such as Firebase Auth, Supabase Auth, Auth0, or AWS Cognito.
    • They manage user accounts, password reset, social logins, multi-factor auth, and often sessions/tokens for you.
  • Discuss benefits:
    • Offload security-sensitive behaviour (password storage, brute-force protection, MFA) to specialists.
    • Faster development: SDKs, UI widgets, and ready-made flows.
    • Built-in support for social/enterprise logins that would be complex to implement yourself.
  • Discuss trade-offs:
    • Vendor lock-in and data model coupling.
    • Less flexibility for unusual requirements.
    • Cost and dependency on an external service for uptime and SLAs.
  • Connect to what trainees have built:
    • Under the hood, these providers typically use the same concepts:
      • Secure password hashing.
      • JWTs or opaque tokens.
      • Sessions/cookies and refresh tokens.
    • In a Node backend, you usually verify a token issued by the provider in middleware and then treat the request as authenticated if verification succeeds.

Comparison, DB tokens & API keys overview, and wrap-up

Goal: Compare the different auth approaches, introduce DB-stored tokens and API keys conceptually, and connect to the assignment.

Comparing auth methods (10–15 min)

  • Revisit the methods you have seen:
    • Secure passwords (with bcrypt) and basic login.
    • JWT-based stateless auth.
    • Session-based auth.
  • Introduce database-stored tokens:
    • Tokens stored in a tokens table, lookup on each request.
    • Easier revocation, but requires a DB call every time.
  • Introduce API keys:
    • Simple secret keys for machine-to-machine communication.
    • Not ideal as the only method for user authentication.
  • Show a comparison table summarising trade-offs:
Method DB Lookup Revocable Scalable Typical use case
Secure credentials Yes No No Legacy / simple systems
Database tokens Yes Yes No Small apps
JWT No Not easy Yes SPAs, mobile apps
Sessions Yes Yes Depends Traditional web apps
API keys No Not easy Yes Machine-to-machine
Third-party auth (IdP) Depends Yes Yes SaaS, bigger products, "don't have time for this"

See Database-stored tokens and API keys for additional details and examples.

Final wrap-up

  • Reiterate best practices:
    • Always use HTTPS.
    • Always hash passwords (bcrypt or similar).
    • Store tokens securely (e.g. HttpOnly cookies for web clients).
    • Prefer short-lived tokens and consider refresh tokens where appropriate.