JWT Expiration Checker

Tính năng nổi bật

• Giải mã header và payload của token ba phần ngăn cách bằng dấu chấm
• Kết luận rõ ba trạng thái: còn hiệu lực, đã hết hạn, hoặc không có trường exp
• Đồng hồ đếm ngược cập nhật mỗi giây theo dạng ngày, giờ, phút, giây còn lại
• Đổi ba trường thời gian exp, iat và nbf từ dấu thời gian Unix sang giờ địa phương
• Hiển thị toàn bộ payload để bạn xem các trường tùy biến như vai trò hay phạm vi quyền
• Nút sao chép payload dạng JSON đã thụt lề, dán thẳng vào phiếu báo lỗi
• Báo lỗi khi chuỗi không đúng định dạng ba phần hoặc không giải mã được
• Giải mã ngay trong trình duyệt, token không được gửi tới máy chủ nào

Hết hạn là nguyên nhân số một khiến một lời gọi API trả về 401

Khi một lời gọi API đang chạy tốt bỗng trả về mã 401, câu hỏi đầu tiên cần trả lời không phải là mã nguồn sai ở đâu mà là token còn hạn không. Rất nhiều buổi gỡ lỗi kéo dài hàng giờ chỉ vì không ai kiểm tra điều đơn giản đó: token lưu trong biến môi trường của công cụ thử API đã hết hạn từ hôm trước, hoặc token trong bộ nhớ trình duyệt được cấp trước khi máy chủ đổi thời hạn. Dán token vào đây mất năm giây và loại bỏ ngay một nửa số giả thuyết. Ngoài lúc gỡ lỗi, công cụ còn hữu ích khi bạn cần biết chính sách thời hạn của một hệ thống đối tác: đọc hiệu số giữa iat và exp là biết token sống bao lâu, từ đó quyết định nên làm mới sau bao nhiêu phút thay vì chờ tới khi nhận lỗi rồi mới thử lại.

Lợi ích khi sử dụng

• •Loại trừ ngay giả thuyết token hết hạn trước khi đi sâu vào gỡ lỗi mã nguồn
• •Biết chính xác còn bao nhiêu thời gian để tính lịch làm mới token
• •Đọc được nội dung payload để kiểm tra vai trò và phạm vi quyền có đúng như mong đợi
• •Thấy được token không có trường exp, một cấu hình rủi ro cần báo lại cho phía cấp token
• •Token không rời khỏi trình duyệt nên an toàn hơn dán vào công cụ trực tuyến có máy chủ

Cách kiểm tra hạn của một JWT

1. 1Lấy token cần kiểm tra, thường nằm ở tiêu đề Authorization sau chữ Bearer, hoặc trong bộ nhớ cục bộ của trình duyệt.
2. 2Dán toàn bộ chuỗi vào ô nhập, nhớ bỏ chữ Bearer và khoảng trắng ở đầu vì chỉ phần token mới giải mã được.
3. 3Bấm nút kiểm tra, ô trạng thái sẽ hiện còn hiệu lực hoặc đã hết hạn kèm thời gian còn lại đếm ngược.
4. 4Đối chiếu ba mốc thời gian: iat là lúc cấp, nbf là mốc bắt đầu có hiệu lực, exp là mốc hết hạn.
5. 5Bấm sao chép payload nếu bạn cần đính kèm nội dung token vào phiếu báo lỗi, nhớ che các trường nhạy cảm trước khi gửi cho người khác.

Ba trường thời gian trong JWT và ý nghĩa của chúng

Cả ba đều là dấu thời gian Unix, tức số giây kể từ nửa đêm ngày 1 tháng 1 năm 1970 theo giờ quốc tế. Trường iat ghi thời điểm token được cấp, dùng để biết token đã bao nhiêu tuổi và cũng là căn cứ để một số hệ thống từ chối token quá cũ dù chưa hết hạn. Trường exp ghi thời điểm hết hạn, sau mốc này máy chủ phải từ chối token. Trường nbf ghi thời điểm bắt đầu có hiệu lực, token dùng trước mốc này cũng bị từ chối; trường này ít gặp hơn nhưng rất hữu ích khi phát token trước cho một sự kiện sẽ mở vào giờ ấn định. Chú ý đơn vị là giây chứ không phải mili giây, đây là nguồn gốc của một lỗi kinh điển: lập trình viên lấy thời gian hiện tại theo mili giây rồi gán thẳng vào exp, khiến token có hạn ở một thời điểm xa hàng nghìn năm sau. Nếu bạn thấy công cụ báo còn hiệu lực với số ngày lớn bất thường, gần như chắc chắn phía cấp token đã nhầm đơn vị. Ba trường này đều là tùy chọn theo đặc tả, nên một token hợp lệ vẫn có thể không có trường nào trong số đó.

Công cụ này giải mã chứ không xác minh chữ ký

Đây là giới hạn quan trọng nhất cần hiểu. Một JWT gồm ba phần ngăn cách bằng dấu chấm: header, payload và chữ ký. Hai phần đầu chỉ được mã hóa Base64 theo biến thể an toàn cho địa chỉ mạng, ai cũng đọc ngược ra được mà không cần khóa. Phần thứ ba là chữ ký, dùng để chứng minh nội dung không bị sửa và token đúng là do bên phát hành cấp. Công cụ này chỉ đọc hai phần đầu, nó không kiểm tra chữ ký vì việc đó cần khóa bí mật hoặc khóa công khai của bên phát hành. Hệ quả thực tế: kết quả còn hiệu lực ở đây chỉ có nghĩa là mốc exp chưa qua, không có nghĩa là máy chủ sẽ chấp nhận token. Một token bị sửa tay phần payload vẫn hiện ra bình thường ở đây nhưng sẽ bị máy chủ từ chối ngay vì chữ ký không khớp. Ngược lại cũng đúng: token còn hạn và chữ ký hợp lệ vẫn có thể bị từ chối nếu đã bị thu hồi, nếu người dùng đổi mật khẩu, hoặc nếu máy chủ kiểm tra thêm các trường về đối tượng nhận và bên phát hành.

Đọc kết quả khi trạng thái là không có exp

Khi công cụ báo không có exp, nghĩa là payload thiếu hẳn trường hết hạn. Về mặt đặc tả thì token vẫn hợp lệ vì exp là trường tùy chọn, nhưng về mặt an toàn thì đây là một cấu hình đáng lo. Token không hết hạn nghĩa là ai lấy được nó sẽ dùng được mãi mãi, kể cả sau khi người dùng đã đăng xuất, trừ khi hệ thống có cơ chế thu hồi riêng bằng danh sách chặn. Trong các hệ thống thực tế, mức thời hạn thường gặp cho token truy cập là từ 5 phút tới 1 giờ, còn token làm mới thì dài hơn, từ vài ngày tới vài tuần, và được lưu ở nơi an toàn hơn. Nếu bạn kiểm tra token của một hệ thống nội bộ và thấy không có exp, đó là điều nên nêu ra khi rà soát bảo mật. Có một trường hợp ngoại lệ hợp lý: một số token dùng để định danh máy chủ với máy chủ trong mạng nội bộ khép kín được cố tình phát không thời hạn và quản lý bằng cách khác, nhưng đó phải là quyết định có cân nhắc chứ không phải sơ suất.

Lệch giờ giữa máy khách và máy chủ

Công cụ so mốc exp với đồng hồ trên máy bạn, còn máy chủ so với đồng hồ của nó. Nếu hai đồng hồ lệch nhau, kết luận có thể khác nhau. Đây không phải chuyện hiếm: máy tính không đồng bộ giờ qua mạng, máy ảo mới khởi động lại, hoặc thiết bị di động vừa đổi múi giờ đều có thể lệch vài giây tới vài phút. Với token thời hạn ngắn kiểu 5 phút, lệch một phút là đủ khiến bạn thấy còn hạn trong khi máy chủ đã từ chối. Vì lý do này, phần lớn thư viện kiểm tra JWT cho phép cấu hình một biên độ dung sai, thường là 30 tới 60 giây, để bỏ qua chênh lệch nhỏ. Khi gỡ lỗi mà thấy công cụ báo còn vài giây nhưng máy chủ vẫn trả 401, việc đầu tiên nên làm là kiểm tra đồng hồ máy mình có được đồng bộ hay không. Cũng lưu ý các mốc thời gian hiển thị ở đây đã đổi sang giờ địa phương của thiết bị, nên nếu bạn so với nhật ký máy chủ ghi theo giờ quốc tế thì phải cộng trừ bảy tiếng cho múi giờ Việt Nam.

Lưu ý an toàn khi thao tác với token thật

Một token truy cập còn hạn có giá trị hệt như mật khẩu: ai cầm được nó sẽ hành động thay bạn trong hệ thống cho tới khi nó hết hạn. Vì thế có mấy nguyên tắc cần giữ. Thứ nhất, chỉ dán token vào công cụ xử lý phía trình duyệt như công cụ này, và bạn có thể tự kiểm chứng bằng cách mở tab mạng trong bảng công cụ dành cho nhà phát triển để thấy không có yêu cầu nào được gửi đi khi bấm kiểm tra. Thứ hai, khi cần chia sẻ token cho đồng nghiệp để tái hiện lỗi, hãy dùng token của tài khoản thử nghiệm chứ đừng dùng token của tài khoản thật, và tốt hơn nữa là chỉ gửi phần payload đã che các trường nhạy cảm. Thứ ba, đừng dán token vào phiếu báo lỗi công khai, tin nhắn nhóm hay ảnh chụp màn hình gửi ra ngoài; nếu lỡ làm vậy thì việc cần làm ngay là thu hồi phiên đó. Thứ tư, nhớ rằng payload của JWT không phải chỗ để giấu thông tin, mọi thứ trong đó đều đọc được, nên không bao giờ đặt số căn cước, số thẻ hay bất kỳ dữ liệu nhạy cảm nào vào payload.

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

Từ khóa liên quan

• kiểm tra hạn jwt
• jwt hết hạn
• giải mã jwt online
• jwt decode tiếng việt
• exp iat nbf trong jwt
• jwt expiration checker
• token hết hạn lỗi 401
• thời hạn access token bao lâu
• refresh token là gì
• jwt có mã hóa không
• xác minh chữ ký jwt
• cấu trúc jwt header payload signature
• unix timestamp là gì
• lệch đồng hồ máy chủ jwt
• bảo mật khi lưu jwt
• jwt không có exp
• đọc payload jwt
• công cụ debug jwt
• kiểm tra token api miễn phí
• jwt an toàn cho url base64url