Security & Authentication

Tags: #◇Web Development #◇CCAPDEV #◇Security & Authentication #◇Conceptual #◇M5

---

◇Overview

Extracted notes for Security & Authentication covering both theoretical and practical elements.

Authentication Models: Session vs. Token

◇Key Definitions

• Session-based Authentication: Users need to have credentials stored in the database for authentication. The server does the heavy lifting to check if the user exists and assigns a unique session ID for the user. This is stateful since the session persists in some server storage.
• Token-based Authentication: The client needs to generate a unique token containing information about the user and this token is sent to the server on every request made. However, no session or record of the user is stored in the database or the server storage which makes it stateless.
• Session-based Pros/Cons: Pros: Session is stored in a database; ensures user authentication through session ID; allows storing additional information. Cons: Database lookup can be time consuming for high-volume apps. Best for: Client-server connections with real users.
• Token-based Pros/Cons: Pros: Lightweight for the server (just check token validity). Cons: Content is decodable (Base64Url); needs to be stored securely. Best for: Server-to-server communication and microservices.
• JSON Web Tokens (JWT): An open standard (RFC 7519) that defines a compact, self-contained way for securely transmitting information between parties as a JSON object.
• Sessions, Tokens, Cookies: For session-based, the server generates a session ID and sends that to the client. For token-based, the server signs a token that has a certain validity. In both cases, the client needs to store that credential somewhere. That’s where cookies or client storage come in.

◇Theoretical Framework

Cookies
A cookie is a small chunk of information stored on the browser, usually sent by the server.
Cookies are used by the browser as a means to preserve the state of being authenticated or keep data for other requests.
This is because web pages have no memories. Navigating to each page in the same app can be treated as a “new” session.

Wait, aren’t sessions stored in the database?
Why do we have to save them in a cookie?
Database querying can be expensive. Cookies are used for faster checking of the session ID and it’s also a way to store the tokens.

Browser Storage
If you use Google Chrome’s Inspect tool, there’s an Application tab there which shows you the different browser storage.
There’s Local Storage, Session Storage and Cookies.
Read more about HTML5 security here.

Sessions
express-session
This is the base package for implementing sessions on your application.
passport + passport-local
Passport.js has a bunch of different authentication strategies that you can use. To use “local” or your own application’s username and password authentication, bundle it with passport-local.

Session Storage
passport-local also uses express-sessions under the hood, so both are customizable.
By default, they use the local MemoryStore in which when the server is restarted, all sessions are deleted. This is not recommended for production (deployed) applications.
There’s a list of compatible session stores that you can choose from. The best is to couple it with the database management system you’re already using for your app (i.e. connect-mongo for mongoose based apps).

◇References & Navigation

• Previous Topic: ◇Cookies and Sessions
• Next Topic: ◇Password Hashing
• Related Notes: ◇Cybersecurity Awareness, ◇Security