JWT bị lộ thì sao? Server phát hiện token giả bằng cách nào?

JWT (JSON Web Token) được dùng rất nhiều trong các hệ thống hiện đại để xác thực người dùng. Nhưng cũng chính vì phổ biến nên JWT thường bị hiểu lầm:

• JWT không mã hóa, vậy nếu hacker sửa payload thì server làm sao biết?
• JWT bị lộ thì có phải coi như hệ thống toang?

Bài viết này sẽ giúp bạn hiểu đúng bản chất của JWT.

1. JWT không mã hóa, nhưng có chữ ký

Một JWT tiêu chuẩn có dạng:

xxxxx.yyyyy.zzzzz

Bao gồm 3 phần:

• Payload có thể decode được → đúng
• Nhưng không thể tự ý sửa → vì có signature

2. Điều gì xảy ra khi hacker sửa payload?

Ví dụ payload ban đầu:

{
  "user_id": 123,
  "role": "user",
  "exp": 1735689600
}

Và hacker decode JWT, sửa thành:

{
  "user_id": 123,
  "role": "admin",
  "exp": 1735689600
}

Vấn đề nằm ở đây: Hacker không có secret key / private key để ký lại token.

Khi request gửi lên server

Server sẽ làm:

1. Tách header.payload.signature
2. Dùng secret key để ký lại header.payload
3. So sánh với signature gửi lên

→ Không khớp → token không hợp lệ → 401 Unauthorized

Payload bị sửa = signature sai = server phát hiện = không thể truy cập hệ thống

3. Vậy “token giả” là giả kiểu gì?

Có 2 loại thường gặp:

1. Token bị sửa payload

   → Bị phát hiện bởi server (signature mismatch)

2. Token tự generate từ client

   → Không có secret → ký sai → server reject

Server sẽ không tin bất cứ token nào không được ký bằng secret key của nó

4. JWT bị lộ thì sao? (Nguy hiểm thật không?)

Có – nhưng không như nhiều người nghĩ

Kịch bản nguy hiểm:

• Token bị đánh cắp (XSS, log, localStorage leak…)
• Token chưa hết hạn
• Không có cơ chế revoke

→ Hacker dùng token đó → server vẫn chấp nhận

Vì server không phân biệt ai đang cầm token

5. Server có phát hiện “token bị đánh cắp” không?

Không, server không thể (theo bản chất JWT stateless)

JWT không lưu trạng thái trên server, nên:

• Không biết token đang ở tay ai
• Không biết token có bị copy hay chưa

→ Đây là trade-off của JWT

6. Cách giảm rủi ro khi JWT bị lộ

1. Token hết hạn ngắn

    exp": 15 phút
   

2. Dùng Refresh Token

   • Access token: ngắn hạn
   • Refresh token: lưu DB, có thể revoke

3. Lưu token đúng chỗ

   Nên	Không nên
   HttpOnly + Secure Cookie	localStorage (dễ XSS)

4. Kiểm tra thêm ở server

   Một số hệ thống làm thêm:

   • Check jti (JWT ID)
   • Check user_status (bị khóa?)
   • Check token_version trong DB

   ➡ Tăng khả năng vô hiệu hóa token

7. JWT không bảo mật là hiểu sai ở đâu?

Sai lầm phổ biến:

JWT phải mã hóa payload mới an toàn

Nhưng thực tế:

• JWT bảo vệ tính toàn vẹn (integrity), không phải bí mật
• Không nên chứa data nhạy cảm (password, secret…)

Nếu cần bí mật → dùng JWE, không phải JWS

8. Tóm tắt nhanh (TL;DR)

• JWT không mã hóa, nhưng có chữ ký
• Payload bị sửa → server phát hiện ngay
• Token giả → không có key → fail
• JWT bị lộ → nguy hiểm cho đến khi hết hạn
• Giảm rủi ro bằng:
  • Exp ngắn
  • Refresh token
  • HttpOnly cookie
  • Cơ chế revoke

9. Khi nào KHÔNG nên dùng JWT?

• Hệ thống cần revoke token ngay lập tức
• Session cực kỳ nhạy cảm
• Muốn kiểm soát trạng thái đăng nhập chặt chẽ

Khi đó, session truyền thống đôi khi lại phù hợp hơn.