JWT là gì? Hướng dẫn toàn diện về JSON Web Token cho người mới

Bạn có bao giờ tự hỏi mỗi lần đăng nhập vào một ứng dụng, “mảnh token” nhỏ xíu ấy thực sự chứa gì bên trong không? JSON Web Token (JWT) là chuẩn mở RFC 7519 giúp truyền thông tin xác thực một cách nhẹ nhàng và an toàn giữa hai bên.

Tiêu chuẩn Internet: RFC 7519 ·
Năm công bố: 2015 ·
Định dạng: JSON, nhỏ gọn, URL-safe ·
Cơ chế bảo mật: Chữ ký số hoặc mã hóa ·
Công cụ phổ biến: npm jwt, jwt.io

JWT được sử dụng để làm gì?

Định nghĩa JSON Web Token

JWT là một chuẩn mở theo RFC 7519, được các tổ chức như IETF (cơ quan chuẩn hóa Internet) thiết lập. Nó cho phép truyền thông tin xác thực dưới dạng JSON gọn nhẹ và tự chứa.

Theo jwt.io (trang giới thiệu chính thức), JWT là chuỗi gồm ba phần: header, payload và signature, tách bởi dấu chấm.

Cấu trúc của JWT: header, payload, signature

RFC 7519 quy định JWT có thể là payload của JWS để được ký hoặc của JWE để được mã hóa.

• Header: chứa loại token và thuật toán ký.
• Payload: chứa dữ liệu (claims) – OWASP (tổ chức an toàn ứng dụng web) khuyến cáo không đặt thông tin nhạy cảm trong payload.
• Signature: xác thực tính toàn vẹn và nguồn gốc.

Điểm mạnh: nhờ chữ ký, JWT không thể bị giả mạo nếu không biết bí mật.

Sự khác biệt giữa OAuth và JWT là gì?

OAuth là framework ủy quyền, JWT là định dạng token

OAuth 2.0 (giao thức ủy quyền do IETF) là một giao thức ủy quyền. JWT lại là định dạng token có thể được dùng làm access token trong OAuth 2.0.

Cách OAuth và JWT hoạt động cùng nhau

OAuth không bắt buộc JWT; nó có thể dùng opaque token (chỗ dữ liệu ngẫu nhiên). Xuất hiện phổ biến: JWT là access token trong OAuth + OpenID Connect (như trong Curity (nền tảng bảo mật OAuth) đề xuất).

Điểm cốt lõi: OAuth và JWT không đối thủ. JWT có thể là phần con của OAuth, nhưng cũng có thể độc lập.

Tại sao nhiều người không khuyến nghị sử dụng JWT?

Vấn đề bảo mật với JWT

Một lỗi phổ biến là dùng thuật toán “none” cho phép kẻ tấn công. PortSwigger (học viện bảo mật web) đã ghi nhận nhiều kỹ thuật tấn công JWT trong tài liệu của họ.

• Dễ bị tấn công nếu secret yếu hoặc dùng thuật toán không an toàn.
• Không thể thu hồi token trước khi hết hạn.

Khó thu hồi token

Khảo sát từ Curity: nên ưu tiên token có thời gian sống ngắn và sử dụng một revocation list.

Kích thước token lớn

JWT chứa toàn bộ payload trong chuỗi, dẫn đến kích thước lớn hơn. Đối với môi trường tốc độ cao, điều này có thể gây ảnh hưởng.

Làm thế nào để đọc một token JWT?

Giải mã header và payload base64

Ví dụ: “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9” giải mã thành {“alg”:”HS256″,”typ”:”JWT”}. Trên jwt.io (trang giới thiệu chính thức) có thể thực hiện dễ dàng.

Sử dụng jwt.io hoặc thư viện npm

Thư viện npm jwt cho phép tạo token, kiểm tra chữ ký. Thư viện khuyên dùng RS256 hoặc ES256 hơn HS256.

1. B1: Tách chuỗi thành 3 phần.
2. B2: Giải mã base64 phần header và payload.
3. B3: Kiểm tra chữ ký bằng thư viện.
4. B4: Xác thực iss, aud và thời gian hết hạn.

Thứ tự kiểm tra theo Kusari (nền tảng bảo mật API): cấu trúc, chữ ký, thuật toán, issuer, audience, expiration.

Giải pháp thay thế tốt hơn cho JWT là gì?

Session cookie truyền thống

Cookie phiên bảo mật, dễ thu hồi, phù hợp cho ứng dụng không cần SSO.

Token opaque (PASETO, Branca)

PASETO được PASETO (thủ tướng thế hệ an toàn hơn JWT) thiết kế để dùng thuật toán mã hóa hiện đại, không cho phép chọn thuật toán “none”.

Mã hóa đầu cuối

Đối với dữ liệu siêu nhạy, hãy sử dụng JWE.

Thực tế: khuyến cáo hiện tại từ Curity và OWASP dùng OAuth 2.0 kết hợp opaque token hoặc JWT sống ngắn – mỗi thứ đều có chỗ của nó.

Dòng thời gian

• 2010: JWT được đề xuất trong cộng đồng OAuth (jwt.io)
• 2015: RFC 7519 được chuẩn hóa bởi IETF (IETF)
• 2016: JWT trở thành định dạng token phổ biến trong OAuth 2.0 và OpenID Connect
• 2020–nay: Các cảnh báo bảo mật về JWT gia tăng; nhiều giải pháp thay thế ra đời

Điều đã xác nhận và điều chưa rõ

Sự thật đã xác nhận

• JWT là tiêu chuẩn RFC 7519 (IETF)
• JWT gồm 3 phần: header, payload, signature (jwt.io)
• JWT không mã hóa payload mặc định (OWASP)
• JWT có thể bị tấn công nếu dùng thuật toán ‘none’ (PortSwigger)
• OWASP khuyến nghị dùng thư viện an toàn và cập nhật (OWASP)

Điều chưa rõ

• Liệu JWT có phù hợp cho tất cả hệ thống xác thực? (tùy ngữ cảnh)
• Hiệu quả của PASETO so với JWT trong thực tế vẫn đang được đánh giá
• Tác động của JWT đến hiệu suất ứng dụng quy mô lớn vẫn chưa được định lượng
• Khả năng thay thế JWT bằng PASETO trong tương lai vẫn chưa rõ ràng
• Tác động của việc lưu trữ JWT trên client so với server-side session vẫn chưa được đánh giá đầy đủ

Trích dẫn từ chuyên gia

“JWT (JSON Web Token) là một chuẩn mở cho phép truyền thông tin dưới dạng JSON một cách gọn nhẹ và tự chứa”

— RFC 7519, IETF (IETF)

“Cần đảm bảo chữ ký hợp lệ và đúng thuật toán mong đợi”

— OWASP Web Security Testing Guide (OWASP)

“Không nên đặt dữ liệu nhạy cảm hoặc dữ liệu kinh doanh trong JWT, đặc biệt khi đi qua ranh giới tổ chức”

— Curity (Curity JWT Security Best Practices)

Kết luận

JWT vẫn là công cụ hữu ích cho xác thực API và SSO, nhưng không phải “thần dược”. Những điểm cần lưu ý: payload không mã hóa, khó thu hồi, và nguy cơ tấn công. Các chuyên gia như OWASP và Curity khuyên dùng token sống ngắn, luôn xác thực signature, và không trusted payload. Đối với nhà phát triển tiếng Việt, cách dùng JWT đúng là: dùng JWT có chữ ký mạnh (RS256), luôn kiểm tra iss + aud, và ưu tiên session cookie cho ứng dụng quy mô vừa không cần SSO.

Người phát triển nên cân nhắc: JWT chỉ an toàn khi biết rõ giới hạn của nó.

Câu hỏi thường gặp

Bài đọc liên quan

• Domain – Hướng dẫn chi tiết từ A đến Z về tên miền (cập nhật 2025)
• SQL – Hướng dẫn toàn diện về SQL Server và cách học