Trình phân tích JWT – JWT parser

Trình phân tích JWT là gì?

Trình phân tích JWT là công cụ giúp chuyển nội dung một chuỗi JSON Web Token sang dạng dễ đọc. JWT là định dạng biểu diễn các thông tin được khai báo, thường dùng để trao đổi dữ liệu về danh tính hoặc phiên truy cập giữa các thành phần của ứng dụng. Tuy nhiên, bản thân việc có một chuỗi JWT không chứng minh người cầm chuỗi đó được phép đăng nhập hay thực hiện một hành động.

Phạm vi công cụ này là chuỗi có ba phần Header, Payload và Signature, phân cách bằng dấu chấm. Công cụ giải mã hai phần đầu từ Base64Url, trình bày nội dung JSON có thụt lề và hiển thị nguyên văn phần chữ ký. Nếu Payload chứa giá trị exp được xử lý, công cụ đối chiếu thời điểm đó với đồng hồ thiết bị để thông báo hạn dùng.

Nhu cầu phù hợp là đọc các trường dữ liệu, hiểu cấu trúc token và kiểm tra sơ bộ thời điểm hết hạn. Kết quả gồm nội dung JSON, chuỗi chữ ký và thông báo trạng thái, không phải chứng nhận xác thực. Đọc được nội dung khác với chứng minh token đáng tin cậy. Công cụ không xác minh chữ ký, không tạo token và không thay thế hệ thống quyết định quyền truy cập.

Các thuật ngữ cần hiểu khi đọc JWT

Header

Header là phần đầu, chứa siêu dữ liệu mô tả token, thường gồm thông tin thuật toán và loại token. Công cụ giải mã phần này để người dùng đọc các trường bên trong. Tên thuật toán xuất hiện chỉ là thông tin được khai báo, không chứng minh chữ ký đã được kiểm tra bằng thuật toán ấy. Cũng cần phân biệt Header của JWT với header của yêu cầu HTTP: chúng thuộc hai cấu trúc khác nhau.

Payload và claim

Payload là phần chứa dữ liệu của JWT; mỗi thông tin được khai báo trong đó gọi là một claim. Claim có thể mô tả chủ thể, đối tượng nhận, thời điểm phát hành hoặc vai trò. Công cụ hiển thị dữ liệu này và xử lý riêng hạn dùng. Chẳng hạn, nhìn thấy một claim vai trò quản trị không có nghĩa người dùng thực sự có quyền quản trị: dữ liệu còn phải được xác minh và đối chiếu chính sách ứng dụng.

Signature

Signature là phần giá trị xác thực mật mã của JWT dạng ký, giúp bên tiếp nhận kiểm tra dữ liệu theo thuật toán phù hợp. Công cụ này chỉ hiển thị chuỗi chữ ký, không đánh giá đúng hay sai. Về kiến thức nền, thuật toán dùng bí mật chung cần khóa bí mật để xác minh; thuật toán bất đối xứng có thể dùng khóa công khai. Vì vậy, không nên hiểu rằng mọi cách xác minh đều cần bí mật của máy chủ.

Base64Url

Base64Url là cách biểu diễn dữ liệu bằng tập ký tự phù hợp khi sử dụng trong URL. Đây là encoding, không phải mã hóa bảo mật hay hàm băm. Công cụ đọc Header và Payload bằng cách đảo ngược biểu diễn này rồi đọc JSON. Việc có thể decode mà không cần khóa là bình thường; nó không đồng nghĩa phá được mã hóa, cũng không chứng minh nội dung chưa bị thay đổi.

exp và NumericDate

exp là claim chỉ thời điểm hết hạn. NumericDate biểu diễn thời gian bằng số giây tính từ mốc Unix, không phải số mili giây và cũng không phải thời lượng còn lại. Công cụ so sánh giá trị này với đồng hồ thiết bị để tính hạn dùng. Điểm cần lưu ý là triển khai chưa kiểm tra đầy đủ kiểu dữ liệu của exp; một giá trị sai đơn vị hoặc sai kiểu có thể dẫn đến kết quả gây hiểu nhầm.

Dữ liệu đầu vào và cách hiểu kết quả

Chuỗi token phù hợp để phân tích

Đầu vào phù hợp là chuỗi ba phần, có đúng hai dấu chấm phân cách. Header và Payload cần đọc được từ Base64Url thành văn bản UTF-8 rồi thành JSON. Với JWT đúng mục đích, hai phần này nên là đối tượng JSON, dù công cụ chưa kiểm tra chặt yêu cầu đó. Gợi ý bắt đầu bằng eyJ trên giao diện không phải điều kiện bắt buộc trong logic.

Khoảng trắng ở đầu và cuối chuỗi được loại bỏ trước khi phân tích. Công cụ không tự bỏ tiền tố Bearer, không xóa khoảng trắng bên trong và không làm sạch tùy ý dữ liệu. Vì vậy, nên cung cấp riêng giá trị token thay vì toàn bộ nội dung một header HTTP. Phần chữ ký rỗng vẫn có thể đi qua bước kiểm tra số phần.

Các vùng kết quả và thông báo trạng thái

Header và Payload được trình bày dưới dạng JSON thụt lề bốn dấu cách, hoặc hiện lỗi riêng nếu không đọc được. Signature giữ nguyên chuỗi phần thứ ba; nếu thiếu nội dung, vùng này hiển thị [Rỗng]. Nó không phải kết quả xác minh chữ ký.

Thông báo trạng thái có thể cho biết đang chờ nhập, sai cấu trúc, Payload lỗi, còn hạn, hết hạn hoặc không có hạn dùng được xử lý. Nhãn màu xanh không có nghĩa xác thực thành công. Thời điểm hết hạn được định dạng tiếng Việt, nhưng múi giờ phụ thuộc môi trường trình duyệt. Thời lượng còn lại chỉ hiện ngày và giờ nguyên.

Công cụ có nút sao chép riêng cho Header và Payload. Chức năng này sao chép văn bản kết quả, không tạo token mới; mã được cung cấp không thể hiện chức năng xuất tệp hoặc nút sao chép chuyên dụng cho Signature.

Công cụ đọc JWT và tính hạn sử dụng như thế nào?

Từ chuỗi Base64Url đến JSON

Sau khi bỏ khoảng trắng hai đầu, công cụ tách chuỗi theo dấu chấm. Nếu không có đúng ba phần, quá trình dừng và báo lỗi định dạng. Với chuỗi phù hợp, Header và Payload được giải mã độc lập, nên lỗi ở một phần không nhất thiết ngăn phần còn lại hiển thị.

Quá trình đọc chuyển các ký tự đặc trưng của Base64Url sang dạng Base64 tương ứng và bổ sung dấu đệm khi cần. Độ dài có số dư một khi chia cho bốn bị từ chối. Sau đó, dữ liệu byte được chuyển thành văn bản UTF-8 và đọc như JSON. Sai biểu diễn Base64, lỗi UTF-8 hoặc văn bản không phải JSON đều có thể làm bước này thất bại; thông báo không phân biệt đầy đủ từng nguyên nhân.

Công cụ còn dựa vào giá trị JSON có được coi là “đúng” trong điều kiện xử lý hay không. Do đó, các giá trị JSON như null, false hoặc số 0 có thể bị báo lỗi dù hợp lệ về cú pháp JSON. Trạng thái tổng thể chủ yếu được quyết định sau khi đọc Payload, không phải bằng một kiểm tra toàn diện cả token.

Phép tính thời gian và các trường hợp biên

Công thức sử dụng là chênh lệch = exp − thời điểm hiện tại, với cả hai tính bằng giây. Thời điểm hiện tại lấy từ đồng hồ thiết bị, bỏ phần lẻ sau khi chuyển từ mili giây. Chênh lệch âm được coi là hết hạn; bằng không hoặc dương đi vào nhánh còn hạn.

Số ngày bằng phần nguyên của chênh lệch chia 86400. Số giờ bằng phần nguyên của phần dư sau khi trừ các ngày trọn vẹn, chia 3600. Vì không hiển thị phút và giây, còn dưới một giờ có thể hiện 0 ngày 0 giờ. Đây là cách lược bớt độ chi tiết, không nhất thiết là hết hạn.

Ở đúng thời điểm exp, công cụ vẫn báo còn hạn vì chỉ xét chênh lệch nhỏ hơn không. Đây là hành vi triển khai, khác yêu cầu thời điểm hiện tại phải trước thời điểm hết hạn. Số 0 trong exp bị bỏ qua; kiểu dữ liệu cũng chưa được kiểm tra đầy đủ. Trạng thái chỉ tính lại khi phân tích được kích hoạt, không có đồng hồ đếm ngược tự cập nhật.

Ví dụ đọc kết quả JWT trong các tình huống khác nhau

Token còn hạn và cách đọc ngày, giờ

Giả sử token có ba phần, Header và Payload là đối tượng JSON mã hóa Base64Url đúng định dạng. Tại lần phân tích, thời điểm hiện tại sau khi lấy phần nguyên là 1700000000 giây, còn exp là 1700089999 giây. Các ví dụ dưới đây được suy ra từ logic, không phải báo cáo chạy thử.

Chênh lệch bằng 89999 giây. Một ngày chiếm 86400 giây, để lại 3599 giây, chưa đủ một giờ. Vì vậy, công cụ hiển thị còn 1 ngày 0 giờ và báo “Token Đang Hoạt Động”. Phần gần một giờ còn lại không xuất hiện trong thời lượng, nhưng vẫn thuộc chênh lệch thực tế. Ngày giờ hết hạn cụ thể phụ thuộc múi giờ trình duyệt; chữ ký chưa được xác minh.

Token đã hết hạn nhưng vẫn đọc được

Giữ thời điểm hiện tại là 1700000000 giây, nhưng giả sử exp bằng 1699999999 giây. Chênh lệch là −1 giây, nên công cụ báo “Token Đã Hết Hạn”. Header và Payload vẫn được trình bày nếu giải mã thành công.

Điều này không mâu thuẫn: thời hạn không làm nội dung Base64Url biến mất hoặc trở nên không thể đọc. Kết quả giúp nhận biết thời điểm được khai báo đã qua, còn ứng dụng có chấp nhận token hay không phải xét thêm quy tắc xác thực của ứng dụng đó.

Trạng thái hợp lệ không đủ để kết luận token đáng tin

Giả sử Header không đọc được, Payload là đối tượng JSON không có exp, còn phần chữ ký rỗng. Công cụ có thể đồng thời hiện lỗi Header, Payload đã định dạng, Signature là [Rỗng] và trạng thái “Token Hợp Lệ”. Cần đọc các vùng kết quả cùng nhau, không lấy nhãn tổng thể làm bằng chứng đăng nhập.

Hai trường hợp biên sau cũng dùng thời điểm hiện tại cố định 1700000000 giây và giả định các phần dữ liệu đọc được:

Khi nào nên dùng trình phân tích JWT?

Đọc dữ liệu thử nghiệm và đối chiếu claim

Công cụ phù hợp khi cần quan sát token thử nghiệm có chứa các thông tin dự kiến hay không. Ví dụ, bạn có thể đọc claim chủ thể, vai trò hoặc đối tượng nhận, rồi đối chiếu với yêu cầu của một tình huống thử nghiệm. Công cụ không tự đánh giá claim đúng với chính sách; phần đối chiếu cần dựa trên thông tin của hệ thống đang sử dụng.

JSON dễ đọc cũng hữu ích khi học cấu trúc JWT hoặc trao đổi một vấn đề với thành viên khác. Nên dùng dữ liệu giả hay nội dung đã loại bỏ thông tin nhạy cảm. Khi chia sẻ, cần nói rõ đó là nội dung đọc từ token chưa được xác minh, tránh để người nhận hiểu một claim vai trò như bằng chứng về quyền thực tế.

Kiểm tra sơ bộ vấn đề thời hạn

Khi ứng dụng từ chối token, phần hạn dùng có thể giúp khoanh vùng ban đầu: thời điểm khai báo đã qua, dữ liệu dùng sai đơn vị hoặc đồng hồ thiết bị khác thời gian hệ thống. Sau đó, cần đối chiếu với phản hồi từ bên xác thực, thay vì kết luận nguyên nhân chỉ từ màn hình này.

Nếu nhiệm vụ là quyết định cho phép truy cập, bước tiếp theo phải là xác minh mật mã và kiểm tra claim theo chính sách ứng dụng. Ảnh chụp kết quả phân tích chỉ giúp trao đổi thông tin, không thay thế quyết định của hệ thống. Công cụ hữu ích ở vai trò đọc và tìm dấu hiệu sơ bộ, không ở vai trò cấp quyền.

Giới hạn cần lưu ý và cách sử dụng thận trọng

Những điều trạng thái không chứng minh

Trạng thái không kiểm tra đầy đủ Header, chữ ký, kiểu dữ liệu của exp, người phát hành, đối tượng nhận, thời điểm bắt đầu hiệu lực hay việc thu hồi token. Vì vậy, kể cả kết quả còn hạn cũng không bảo đảm ứng dụng sẽ chấp nhận. Không có hạn dùng được xử lý cũng không có nghĩa token tồn tại mãi: máy chủ có thể áp dụng thời hạn phiên hoặc quy tắc khác.

Logic chỉ nhận dạng ba phần; dạng JWE compact năm phần nằm ngoài phạm vi. Công cụ cũng không có chức năng tạo, ký, mã hóa hay xuất token mới. Việc đọc hoặc sao chép JSON không tạo ra một JWT thay thế có chữ ký hợp lệ.

Quyền riêng tư và phụ thuộc trình duyệt

Đoạn mã phân tích được cung cấp dùng API trình duyệt và không thể hiện thao tác gửi token. Tuy nhiên, chưa có mã toàn bộ trang, các script khác hoặc cấu hình triển khai để xác minh toàn trang không gửi hay lưu dữ liệu. Tuyên bố xử lý offline trên giao diện vì thế không nên được coi là bảo đảm bảo mật đã kiểm chứng.

Không nên dán token đang dùng vào môi trường chưa được đánh giá. Clipboard và bản JSON chia sẻ cũng có thể chứa dữ liệu nhạy cảm. Đồng hồ thiết bị ảnh hưởng phép tính, múi giờ ảnh hưởng cách hiển thị, còn quyền clipboard có thể khiến sao chép thất bại. Nếu để màn hình lâu, trạng thái có thể cũ vì không tự cập nhật theo thời gian.

Decode JWT khác gì xác minh chữ ký và giải mã JWE?

Decode Base64Url là đọc lại dữ liệu từ một cách biểu diễn. Nó giúp chuyển Header và Payload sang văn bản JSON, không cần chứng minh ai đã tạo dữ liệu. Làm đẹp JSON chỉ thay đổi cách trình bày cho dễ quan sát; đó cũng không phải thao tác bảo mật.

Xác minh chữ ký là kiểm tra bằng thuật toán và khóa phù hợp xem giá trị xác thực mật mã có khớp dữ liệu hay không. Sau bước này, hệ thống vẫn cần kiểm tra những điều kiện chấp nhận như người phát hành, đối tượng nhận và thời hạn. Đây là các việc công cụ phân tích hiện tại không thực hiện.

Encryption nhằm bảo vệ tính bí mật của dữ liệu, còn hashing tạo giá trị băm và không phải cách đọc ngược nội dung như Base64Url. JWT dạng ký không mặc nhiên che giấu Payload. JWE là định dạng mã hóa khác; dạng compact năm phần của nó không được logic ba phần này hỗ trợ.

Vị trí phù hợp của công cụ là giúp hiểu nội dung trước khi điều tra hoặc đối chiếu. Quyết định tin cậy phải dựa vào xác minh và chính sách của hệ thống, không dựa riêng vào việc decode thành công hay một nhãn trạng thái thuận mắt.

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

Công cụ báo Token Hợp Lệ nhưng ứng dụng vẫn từ chối đăng nhập thì sao?

Điều đó có thể xảy ra vì “Token Hợp Lệ” chỉ là nhãn của nhánh xử lý nội dung, không phải xác nhận đăng nhập. Ứng dụng có thể từ chối do chữ ký sai, người phát hành không được chấp nhận, đối tượng nhận không phù hợp hoặc token đã bị thu hồi. Hãy đối chiếu thông báo từ hệ thống xác thực và chính sách liên quan. Đừng dùng kết quả màu xanh để bỏ qua lỗi riêng trong Header hoặc phần chữ ký.

Vì sao thời gian còn lại hiển thị 0 ngày 0 giờ?

Thông thường, đó là vì thời lượng còn lại chưa đủ một giờ và công cụ không hiển thị phút, giây. Các đơn vị ngày và giờ đều lấy phần nguyên, nên một khoảng dương ngắn vẫn có thể xuất hiện như vậy. Ngoài ra, đúng thời điểm hết hạn cũng đi vào nhánh còn hạn của triển khai. Cần đọc cả thời điểm hết hạn, đối chiếu đồng hồ và nhớ rằng hệ thống tiếp nhận có thể đánh giá hiệu lực khác nhãn này.

Nếu exp dùng mili giây thay vì giây thì kết quả có đáng tin không?

Không nên tin kết quả hạn dùng khi exp dùng sai đơn vị. Công cụ tính toán với giả định giá trị là số giây từ mốc Unix; đưa số mili giây vào sẽ làm thời điểm và thời lượng bị diễn giải sai. Nó không tự nhận diện đơn vị để chuyển đổi giúp bạn. Hãy đối chiếu ý nghĩa giá trị với tài liệu hoặc dữ liệu phát hành của hệ thống, thay vì chỉ dựa vào việc ngày giờ đã xuất hiện trên màn hình.

Để nguyên token trên màn hình thì trạng thái hết hạn có tự cập nhật không?

Không. Mã được cung cấp tính hạn dùng khi thao tác phân tích được kích hoạt, chẳng hạn lúc nội dung nhập thay đổi; không có bộ hẹn giờ liên tục kiểm tra. Vì thế, một kết quả còn hạn có thể vẫn nằm trên màn hình sau khi thời điểm hết hạn đã qua. Nếu cần đánh giá lại, hãy kích hoạt một lần phân tích mới. Dù vậy, thời gian vẫn lấy từ thiết bị và không thay thế phép kiểm tra của máy chủ.

Có thể dán cả tiền tố Bearer vào ô nhập không?

Nên dán riêng chuỗi token, không kèm tiền tố Bearer. Công cụ chỉ loại bỏ khoảng trắng ở hai đầu, không tự tách giá trị từ header xác thực HTTP. Nếu giữ tiền tố, chuỗi có thể vẫn có đúng số dấu chấm nhưng phần đầu không còn là Header Base64Url dự kiến, dẫn đến lỗi hoặc kết quả khó hiểu. Chỉ bỏ phần tiền tố bên ngoài token, không tùy ý xóa hay thay ký tự trong các phần dữ liệu.

Vì sao nút sao chép không hoạt động dù đã có kết quả?

Sao chép phụ thuộc API clipboard, quyền truy cập và môi trường trình duyệt, nên có kết quả không bảo đảm thao tác thành công. Ngoài ra, công cụ bỏ qua sao chép nếu ô kết quả rỗng hoặc chứa chữ “LỖI”. Điều kiện này áp dụng cả khi chữ ấy nằm trong nội dung JSON hợp lệ, không chỉ trong thông báo lỗi. Chưa có thông tin để xác nhận quyền clipboard trên thiết bị của bạn; khi API thất bại, công cụ có thông báo lỗi sao chép.

Có nên dán token đang dùng thật vào công cụ này không?

Nên ưu tiên token thử nghiệm hoặc dữ liệu giả nếu chưa đánh giá môi trường sử dụng. Token thật có thể mang thông tin cá nhân hoặc khả năng truy cập tài nguyên, nên cần được xử lý như dữ liệu nhạy cảm. Đoạn mã hiện có không thể hiện gửi token, nhưng chưa đủ để xác nhận hành vi toàn bộ trang. Cũng cần cân nhắc rủi ro khi đưa kết quả vào clipboard, ảnh chụp hay tin nhắn chia sẻ, dù chỉ muốn nhờ người khác đọc claim.