The Fundamentals You Need to Build a Chat Room UPDATING 

The TCP Three-Way Handshake Client — Server Purpose of the three-way handshake: the client’s send and receive are both fine, and the server’s send and receive are both fine. First handshake: the client sends SYN (synchronize request) Client: I know nothing, so I’ll send out a SYN message and see if anyone receives it. If no one replies, I send it a few more times (timeout retransmission). At this moment, what the client knows is: I sent it, but I don’t know whether anyone received it ❌ Can I receive messages? Unknown ❌ Does the other side exist? Unknown ❌ Second handshake: the server replies SYN+ACK (synchronize + acknowledge) The server received the client’s SYN. ...

2026-04-03 11:45:26 AM · 17 min

Why the Backend Sometimes Needs to Maintain a Refresh_Tokens Table

The Normal JWT Request Flow sequenceDiagram participant User as User participant Frontend as Frontend (browser/app) participant Auth as Auth server participant Backend as Backend API server Note over User,Backend: 1. Login phase User->>Frontend: enter username/password Frontend->>Auth: POST /login (credentials) Auth->>Auth: verify credentials Auth-->>Frontend: return access_token + refresh_token Frontend->>Frontend: store tokens (memory/localStorage) Frontend-->>User: login successful Note over User,Backend: 2. Normal request phase User->>Frontend: request a protected resource Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token Backend->>Backend: verify access_token signature and expiry Backend-->>Frontend: return the requested resource Frontend-->>User: display data Note over User,Backend: 3. Access token expires User->>Frontend: keep requesting Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token (expired) Backend-->>Frontend: 401 Unauthorized (token expired) Frontend->>Frontend: detects 401, triggers refresh logic Note over Frontend,Auth: 4. Token refresh phase Frontend->>Auth: POST /refreshrefresh_token Auth->>Auth: verify refresh_token Auth-->>Frontend: return a new access_token (optionally a new refresh_token) Frontend->>Frontend: update the stored access_token Frontend->>Backend: retry the original request (new access_token) Backend-->>Frontend: return the requested resource Frontend-->>User: display data Why You Can’t Rely on JWT Alone Once a refresh token is issued and the backend doesn’t store it, it becomes an uncontrollable long-term pass You can’t forcibly log a user out You can’t log out a single device You can’t tell whether a token has been stolen (an attacker who gets the refresh token can keep refreshing the access token forever) You can’t implement session management The Flow After Using a refresh_tokens Table sequenceDiagram participant User as User participant Frontend as Frontend participant Auth as Auth server participant DB as Database (refresh_tokens table) participant Backend as Backend API server Note over User,DB: 1. Login phase (issue token + persist) User->>Frontend: enter username/password Frontend->>Auth: POST /login Auth->>Auth: verify credentials Auth->>DB: generate a unique refresh_token_idINSERT INTO refresh_tokens(user_id, token_hash, expires_at, device_info, ip_address, revoked) DB-->>Auth: insert successful Auth->>Auth: generate access_token + refresh_token(refresh_token contains the id reference) Auth-->>Frontend: return access_token + refresh_token Frontend->>Frontend: store tokens Frontend-->>User: login successful Note over User,Backend: 2. Normal request (same as before) User->>Frontend: request a resource Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token Backend->>Backend: verify access_token Backend-->>Frontend: return the resource Note over Frontend,DB: 3. Access token expires → refresh Frontend->>Backend: GET /api/resource (access_token expired) Backend-->>Frontend: 401 Unauthorized Frontend->>Auth: POST /refreshrefresh_token Note over Auth,DB: 4. Refresh verification (multi-step checks) Auth->>Auth: parse refresh_token, extract token_id Auth->>DB: SELECT * FROM refresh_tokensWHERE id = token_id DB-->>Auth: return the record Auth->>Auth: verification checklist: Note over Auth: ✅ does token_hash match✅ is it expired (expires_at > now())✅ is it revoked (revoked = false)✅ is the user still valid✅ does device info match (optional) alt all checks pass Auth->>DB: UPDATE refresh_tokensSET last_used_at = now(), last_used_ip = current_ipWHERE id = token_id Auth->>Auth: generate a new access_token(optional: extend refresh_token validity) Auth-->>Frontend: return the new access_token Frontend->>Frontend: update access_token Frontend->>Backend: retry the original request (new token) Backend-->>Frontend: return the resource else checks fail Auth-->>Frontend: 401/403 (refresh failed) Frontend->>Frontend: clear all tokens Frontend->>User: redirect to the login page end Note over User,DB: 5. Explicit logout User->>Frontend: click logout Frontend->>Auth: POST /logoutrefresh_token Auth->>DB: UPDATE refresh_tokensSET revoked = trueWHERE id = token_id Auth-->>Frontend: logout successful Frontend->>Frontend: clear local tokens Frontend-->>User: logged out Note over User,DB: 6. Security scenario: password change User->>Frontend: change password Frontend->>Auth: POST /change-password Auth->>DB: UPDATE refresh_tokensSET revoked = trueWHERE user_id = current_user_id Note over DB: revoke all of the user's refresh_tokens(force all devices to log in again) Auth-->>Frontend: password change successful Frontend->>Frontend: clear local tokens Frontend-->>User: please log in again

2026-03-02 08:07:07 PM · 3 min