Authentication Work Flow

session.md

Authentication Work Flow

Sesssions

---

Flow

• user submits login credentials, e.g email and password
• server verifies the credentials against the DB
• server creates a temporary user session
• server issues a cookie with a session ID
• user sends the cookie with each request
• server validates the cookie against the session store and grants access
• when user logs out, server destorys the session and clear the cookie

Features

• every user session is stored server-side(statefull)
  • memory e.g file system
  • cache e.g Redis; or
  • DB e.g Mongo
• user is identified by a session ID
  • opaque; meaning
    • no 3rd party can extract data out
    • only issuing server can map the session ID back to the secure data.
  • stored in a cookie
    • signed with a secret

Cookies

• Cookie header is just like Authorization or Content-Type
• used in session management, tracking
• consists of name, values and optional attributes / flags

Usage

• Set-Cookie by server, and appended with Cookie by browser

Attributes

• Domain and Path; can only be used on a given site and route
• Expiration; can only be used until expiry
  • when omitted, becomes a session cookie
  • gets deleted when browser is closed

Flags

• HttpOnly; cannot be read with JS on the client-side
• Secure; can only be sent encrypted HTTPS channel,
• SameSite; can only be sent from the same domain, i.e no CORS sharing

sessionsVSjwt.md

Session vs JWT

---

Session + Cookies

Pros

• sessions IDs are opaque and carry no meaningful data
• cookies can be secured with flags
• HTTP-only cookie are not susceptiable to JS XSS attacks

Cons

• server must store each user session in memory
• session auth must be secured against CSRF
• horizontal scaling is more challenging
  • risk of single point of failure
  • need sticky session with load balancing on the server(s)

JWTs

Pros

• server does not need to keep track of the user sessions
• horizontal scaling is easy as any server could verify the token as long as they have the SECRET
• CORS is not an issue if the Authorization header is used over the Cookie
• Front and backend architecture is decoupled; can be used with mobile apps
• opeational even if cookie are disabled; via Authoization header

Cons

• server still has to maintain a list of white token for active users
• when scaling, the secret must be shared between severs
• data stored in token is cached and can go stale(out of sync); not a problem if nothing more than an ID is stored
• tokens stored in client storage are vulnerable to XSS
• requires JavaScript to be enabled

Important

Regardless of what is used:

• XSS can compromise user accounts:
  • by leaking tokens from localStorage
  • via AJAX request with user token in Authorization
  • via AJAX request with HttpOnly cookies
• SSL/HTTPS must be configured
• security header must be set

Measure to combat

• IP verification
• user agent verification
• two-factor authentication
• API throttling

token.md

Authentication Work Flow

Token

---

Flow

• user submits login credentials, e.g email and password
• server verifies the credentials against the DB
• server generate a temporary token and embeds only a userId; meaning no sensitive materail
• server respond back with the token(in the header or body)
• user stores the token in client storage e.g localStorage but this is frowned upon.
• user send the token along with each request.
• server verifies the token(with the SECRET) and grants (or denies) access
• when user logs out, the token should be cleared from client storage.

Features

• tokens are not stored server-side; stored on the client-side(stateless)
• signed with a secret against tampering
  • verified and can be trusted by the server
• tokens can be:
  • opaque
    • no secure user data.
    • only an id which is then used by the server to find the secure data
  • self-contained
    • carries all required user data in its payload
    • reduces the need for sever/database calls, but expose data to XSS
• typically sent in Authorization header
• when a token is about to expire, it can be refreshed; not recommended I have read.
• used is SPA web apps, web apis and mobile apps,

JWT JSON Web Token

• open standard for authorization and info exchange
• compact, self-contained, URL-safe tokens
• signed with a secret

Client-Storage

• JWTs can be stored in client storage, localStorage or sessionStorage
  • localStorage has no expiry time; however, the token can,
  • sessionStorage gets cleared when the page is closed

localStorage

Browser key-value store with a simple API With node.js use npm package localForage

Pros

• domain-specific, each site has its own, other sites cannot read/write
• max size higher than cookie (5MB / domain vs. 4KB / cookie)

Cons

• plaintext; not very secure
• limited to string data; therefore serialize with JSON.stringify
• cannot be used by web workers
• stored untiled explicitly removed
• accessible to any JS code running on the page (including XSS)

Best For

• public, non-sesitive data, string data
• a userID that will only map to data throught the server with access to the DB

Bad For

• offline capabilities
• non-string data; e.g object, arrays
• private, secure data