Sau khi bạn đăng nhập, làm thế nào máy chủ biết rằng mỗi yêu cầu sau đó thực sự là của bạn? Một câu trả lời phổ biến là Mã thông báo Web JSON hay JWT, thường được phát âm là “jot”. Đó là một đoạn dữ liệu nhỏ có chữ ký mà khách hàng gửi với mỗi yêu cầu và máy chủ có thể kiểm tra nó mà không cần chạm vào cơ sở dữ liệu.

Cách nhanh nhất để hiểu JWT là xây dựng một JWT và sau đó thử phá vỡ nó. Chúng tôi đã làm điều đó chỉ bằng cách sử dụng thư viện chuẩn của Python, trên Python 3.13 và kết quả đầu ra bên dưới là từ lần chạy đó. Mã này dành cho việc học. Trong ứng dụng thực tế, hãy sử dụng thư viện được bảo trì tốt vì các chi tiết xác minh rất dễ bị sai.

JWT là gì?

JWT là một tiêu chuẩn mở, được định nghĩa trong RFC 7519, để chuyển các yêu cầu giữa hai bên dưới dạng một chuỗi nhỏ gọn. Xác nhận quyền sở hữu chỉ đơn giản là một tuyên bố, chẳng hạn như “ID của người dùng này là 42”. Vì mã thông báo đã được ký nên người nhận có thể xác nhận ai đã phát hành mã thông báo đó và không ai thay đổi mã thông báo đó.

Hãy nghĩ về một chiếc vòng tay lễ hội. Nhân viên tại cổng kiểm tra vé của bạn một lần và đưa cho bạn một chiếc vòng tay khó làm giả. Sau đó, mỗi gian hàng chỉ cần nhìn ban nhạc mà không cần gọi điện tới phòng bán vé. JWT hoạt động theo cách tương tự đối với API.

Cách đăng nhập JWT hoạt động

1. Người dùng gửi tên người dùng và mật khẩu đến điểm cuối đăng nhập.
2. Máy chủ kiểm tra chúng và tạo mã thông báo đã ký.
3. Khách hàng lưu trữ mã thông báo.
4. Mỗi yêu cầu sau này đều bao gồm nó, thường ở tiêu đề: Authorization: Bearer <token>.
5. Máy chủ xác minh chữ ký và thời hạn sử dụng, sau đó đọc các khiếu nại.

Lợi ích chính nằm ở bước 5. Máy chủ không phải tra cứu phiên, thuận tiện khi nhiều dịch vụ hoặc máy chủ cần kiểm tra cùng một token. Nếu bạn chưa quen với API, hãy bắt đầu với API là gì.

Ba phần của JWT

JWT trông giống như văn bản ngẫu nhiên, nhưng nó là ba phần được mã hóa Base64URL được phân tách bằng dấu chấm. Đây là một cái chúng tôi đã tạo:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

Chúng tôi đã thêm ngắt dòng để dễ đọc hơn. Giải mã hai phần đầu tiên cho JSON đơn giản:

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

Yêu cầu tiêu chuẩn

Bạn cũng có thể thêm các xác nhận quyền sở hữu tùy chỉnh, như role. Thời gian là dấu thời gian Unix, tính bằng giây. Giữ tải trọng nhỏ vì mã thông báo sẽ di chuyển theo mọi yêu cầu.

Tự mình xây dựng một cái

Việc tạo mã thông báo bao gồm việc mã hóa hai phần JSON, sau đó ký chúng bằng một bí mật bằng cách sử dụng HMAC-SHA256:

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

Quá trình xác minh hoạt động bằng cách tính toán lại chữ ký và so sánh nó với chữ ký trong mã thông báo. Chỉ người có bí mật mới có thể tạo ra bí mật phù hợp:

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

Mã thông báo hợp lệ đã trả lại yêu cầu của nó như mong đợi. compare_digest được sử dụng vì nó chạy trong thời gian không đổi, giúp tránh rò rỉ thông tin do chênh lệch thời gian.

Cố gắng can thiệp vào nó

Giả sử kẻ tấn công giải mã tải trọng, thay đổi "role":"user" thành "role":"admin", mã hóa lại và giữ chữ ký cũ. Chúng tôi đã thử điều này cùng với hai cuộc tấn công khác:

Nỗ lực cuối cùng đó nhằm vào một điểm yếu lịch sử thực sự. Một số thư viện từng tin cậy tiêu đề riêng của mã thông báo, vì vậy kẻ tấn công có thể chỉ cần tuyên bố rằng không cần chữ ký. Mã của chúng tôi luôn sử dụng một thuật toán cố định, đó là lý do tại sao nó bị từ chối. Trong thư viện thực, hãy luôn chỉ định các thuật toán bạn chấp nhận.

Đã ký, không được mã hóa

Đây là điểm bị hiểu lầm nhiều nhất về JWT. Mã thông báo giả mạo của chúng tôi đã bị từ chối nhưng nội dung của nó vẫn hoàn toàn có thể đọc được:

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL là một mã hóa, không phải mã hóa và bất kỳ ai cũng có thể đảo ngược nó mà không cần khóa. Chữ ký ngăn mọi người thay đổi dữ liệu chứ không ngăn đọc dữ liệu đó. Vì vậy, đừng bao giờ đặt mật khẩu, số thẻ hoặc dữ liệu cá nhân riêng tư vào tải trọng JWT. Nếu nội dung phải bị ẩn, hãy sử dụng mã thông báo được mã hóa (JWE) hoặc chỉ giữ dữ liệu trên máy chủ.

HS256 so với RS256

Với việc ký bất đối xứng, các dịch vụ khác có thể xác minh mã thông báo mà không thể tạo ra mã thông báo của riêng chúng, điều này sẽ hạn chế thiệt hại nếu một mã bị xâm phạm.

JWT so với phiên

JWT thường được trình bày như một sự thay thế hiện đại cho các phiên. Trong thực tế, mỗi cái đều có sự đánh đổi:

Đối với trang web được hiển thị trên máy chủ truyền thống, cookie phiên thường đơn giản và an toàn hơn. JWT có xu hướng có ý nghĩa hơn đối với các API được sử dụng bởi một số dịch vụ hoặc đối với ứng dụng khách trên thiết bị di động.

Nơi lưu trữ mã thông báo trong trình duyệt

Nhiều hướng dẫn bảo mật ưu tiên cookie HttpOnly, Secure, SameSite cho ứng dụng web. Dù bạn chọn cách nào, hãy luôn sử dụng HTTPS. Để gửi mã thông báo từ JavaScript, hãy xem Hướng dẫn API tìm nạp JavaScript của chúng tôi.

Làm mới mã thông báo

Thời hạn sử dụng ngắn sẽ hạn chế thiệt hại do mã thông báo bị đánh cắp, nhưng không ai muốn đăng nhập sau mỗi 15 phút. Giải pháp thông thường sử dụng hai mã thông báo:

• Mã thông báo truy cập: tồn tại trong thời gian ngắn, chẳng hạn như số phút và được gửi cùng với mọi yêu cầu API.
• Mã thông báo làm mới: tồn tại lâu hơn, được lưu trữ cẩn thận hơn và chỉ được sử dụng để nhận mã thông báo truy cập mới.

Máy chủ theo dõi các mã thông báo làm mới, do đó, nó có thể thu hồi chúng, giúp bạn đăng xuất một cách thiết thực. Xoay chúng trong mỗi lần sử dụng cũng giúp bạn phát hiện hành vi trộm cắp vì mã thông báo cũ bị đánh cắp sẽ được phát lại.

Những lỗi bảo mật thường gặp

• Giải mã mà không cần xác minh. Việc đọc tải trọng không làm cho nó trở nên đáng tin cậy. Luôn kiểm tra chữ ký.
• Chấp nhận bất kỳ thuật toán nào. Đặt danh sách rõ ràng các thuật toán được phép.
• Sử dụng bí mật yếu. Bí mật ngắn có thể bị bẻ khóa ngoại tuyến. Sử dụng một giá trị ngẫu nhiên dài và giữ nó ngoài tầm kiểm soát nguồn.
• Bỏ qua thời hạn sử dụng. Token không có exp có thể hoạt động mãi mãi nếu bị đánh cắp.
• Không kiểm tra iss và aud. Nếu không, mã thông báo được cấp cho một dịch vụ có thể được dịch vụ khác chấp nhận.
• Tin vào các tuyên bố cũ. Vai trò bên trong mã thông báo có thể lỗi thời cho đến khi hết hạn.
• Mã thông báo ghi nhật ký. Bất kỳ ai đọc nhật ký của bạn đều có thể sử dụng lại chúng.
• Không kiểm tra các đường dẫn lỗi. Thêm các thử nghiệm cho các mã thông báo đã hết hạn và đã sửa đổi cũng như các mã thông báo hợp lệ. Hướng dẫn kiểm tra API bằng Postman của chúng tôi có thể giúp ích.

Lời kết

JWT là dữ liệu đã được ký mà máy chủ có thể tin cậy mà không cần tra cứu, không phải là vùng chứa bí mật và không phải là bản nâng cấp tự động qua các phiên. Sử dụng thời hạn sử dụng ngắn, xác minh mọi thứ bằng thư viện được duy trì và loại bỏ dữ liệu riêng tư khỏi tải trọng. Để tự mình xem, hãy chạy một tập lệnh nhỏ như của chúng tôi, thay đổi một ký tự của mã thông báo và xem quá trình xác minh không thành công.

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

Tiếp tục học hỏi