Lesson 6: Sessions, Authentication, and Secure Integration

HTTP is stateless: every request stands alone, and the server forgets you the moment it responds. Yet applications must remember who is logged in across many requests. The classic solution is the session: after login, the server creates a session record and gives the browser a cookie holding a random session ID; the browser sends the cookie with every request, and the server looks up who you are. The modern alternative for APIs is the token, most commonly a JWT (JSON Web Token): the server signs a small JSON payload (user id, expiry) and hands it to the client, which sends it back in the Authorization: Bearer header. Sessions keep state on the server; JWTs keep it on the client with a tamper-proof signature. Know both flows step by step — "trace what happens when a user logs in" is a staple exam question.

These two words are the most confused pair in the course. Authentication answers "who are you?" — verifying identity with a password, one-time PIN, or fingerprint. Authorization answers "what may you do?" — checking permissions after identity is known. A student and a registrar both authenticate into the school portal, but only the registrar is authorized to edit grades. Standard building blocks: password hashing (store bcrypt hashes, never plaintext — if the database leaks, passwords stay secret), multi-factor authentication (password + SMS or authenticator code, now common in Philippine banking apps), and role-based access control (RBAC) — assign roles like student, cashier, admin, and check the role on every protected endpoint. The check must happen on the server for every request; hiding a button in the app is not authorization.