Authentication & Authorization: JWTs, Sessions and RBAC
SecurityAuthentication proves who you are; authorization decides what you may do. Sessions keep the state on the server; JWTs carry signed claims the server can verify without a lookup; RBAC maps users to roles to permissions.
A session is a coat-check ticket: the ticket is meaningless alone and the cloakroom looks up the coat. A JWT is a signed pass that states your name and access, and any guard can check the signature. RBAC is the list of which pass colours open which doors.
Sessions. After login the server creates a random session id, stores the session (user, expiry) in Redis or a database, and sets it in a cookie. Each request is a lookup. Revoking is trivial - delete the record - and the cookie holds nothing sensitive, but every request touches the store.
JWT structure. A JSON Web Token is three base64url parts: header.payload.signature. The payload holds claims (sub user id, exp expiry, iat, roles). The signature is an HMAC (HS256, a shared secret) or a public-key signature (RS256) over the first two parts. The payload is encoded, not encrypted: anyone can read it, so no secrets inside.
import base64, hashlib, hmac, json
def b64(b): return base64.urlsafe_b64encode(b).rstrip(b'=').decode()
def sign(payload, secret):
head = b64(json.dumps({'alg': 'HS256', 'typ': 'JWT'}).encode())
body = b64(json.dumps(payload).encode())
sig = hmac.new(secret, f'{head}.{body}'.encode(), hashlib.sha256).digest()
return f'{head}.{body}.{b64(sig)}'Verifying correctly. Recompute the signature and compare with hmac.compare_digest (constant time); check exp (and nbf, iss, aud); and pin the algorithm you expect. Classic bugs: accepting alg: none, or letting an attacker switch an RS256 token to HS256 and sign with your public key.
The JWT trade-off. Stateless verification scales without a shared store, but you cannot easily revoke one before it expires. Standard answer: short-lived access tokens (5-15 minutes) plus a longer-lived refresh token stored server-side and rotated on use, so logout and compromise can be handled.
Cookie hygiene. Whether it holds a session id or a token: HttpOnly (scripts cannot read it), Secure (HTTPS only), SameSite=Lax/Strict, a sensible expiry, and a new id after login to prevent session fixation. Use a cryptographically random id (at least 128 bits), never a counter or timestamp.
Passwords. Store a slow, salted hash (bcrypt, scrypt, Argon2), never the password or a fast hash. Rate-limit login attempts and respond identically for 'unknown user' and 'wrong password'.
RBAC. Users have roles, roles have permissions, and the code asks a permission question (can(user, 'invoice:approve')) instead of testing role names. Roles can inherit (admin includes editor includes viewer). Enforce on the server on every request, deny by default, and keep the check in one place. For finer rules ('only your own documents') add attribute-based checks on top.
- Authentication = who you are; authorization = what you may do.
- Sessions are revocable but need a lookup; JWTs verify statelessly but are hard to revoke.
- A JWT payload is readable by anyone: sign it, do not put secrets in it.
- Verify signature in constant time, check exp, and pin the algorithm.
- RBAC: users -> roles -> permissions, checked server-side, deny by default.
Curated Curation & Deep Insights
ScaleDojo CertifiedOur system architects are vetting high-quality, authorized video guides for Authentication & Authorization: JWTs, Sessions and RBAC with zero third-party platform links.
We are preparing premium, zero-competitor deep-dives for Authentication & Authorization: JWTs, Sessions and RBAC. Authorized reading references will appear automatically.