CHƯƠNG 1 GIỚI THIỆU VỀ SPRING BOOT
1.4. Json Web Token (JWT)
1.4.1 JWT là gì?
Json Web Token là một chuỗi mã hóa mà nguồn gốc ban đầu là một chuỗi JSON. Chuỗi thơng tin dạng JSON bằng phương pháp mã hóa nào đó, nó trở thành 1 chuỗi ký tự lộn xộn nhìn vào sẽ rất khó hiểu.
Theo định nghĩa tiêu chuẩn thì JSON Web Token (JWT) là 1 tiêu chuẩn mở (RFC 7519) định nghĩa một cách nhỏ gọn và khép kín để truyền một cách an tồn thơng tin giữa các bên dưới dạng đối tượng JSON. Thơng tin này có thể được xác minh và đáng tin cậy vì nó có chứa chữ ký số. JWTs có thể được ký bằng một thuật tốn bí mật (với thuật tốn HMAC) hoặc một public/private key sử dụng mã hóa RSA.
Như vậy, bảo mật JWT là phương pháp xác thực quyền truy cập (Authentication) bằng JSON Web Token.
1.4.2 Cấu trúc của một JWT
JSON Web ToKen bao gồm 3 phần, được ngăn cách bởi dấu chấm (.) được minh họa trong hình 1.12 :
1. Header 2. Payload
Hình 1. 10: Cấu trúc của JWT
1.4.2.1 Header
Header bao gồm hai phần chính:
typ – Loại token (mặc định là JWT – cho biết đây là một Token JWT). alg – Thuật tốn đã dùng để mã hóa (HMAC SHA256 – HS256 hoặc RSA).
Hình 1. 11: Hình ảnh ví dụ của một Header
1.4.2.2 Payload
Payload là nơi chứa các nội dung của thơng tin (claim). Thơng tin truyền đi có thể là mơ tả của 1 thực thể (ví dụ như người dùng) hoặc cũng có thể là các thơng tin bổ sung thêm cho phần Header. Chúng được chia làm 3 loại: reserved, public và private.
Reserved : là những thông tin đã được quy định ở trong IANA JSON Web
Token Claims registry. Những thơng tin này khơng có cái nào là bắt buộc cả. Tuy nhiên tùy vào từng ứng dụng implement mà ràng buộc yêu cầu bắt buộc đối với những thông tin cần thiết.
o iss (issuer): tổ chức phát hành token (không bắt buộc)
o sub (subject): chủ đề của token (không bắt buộc)
o aud (audience): đối tượng sử dụng token (không bắt buộc)
o exp (expired time): thời điểm token sẽ hết hạn (không bắt buộc)
o nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này
o iat (issued at): thời điểm token được phát hành, tính theo UNIX time
Public: Khóa có thể define tùy theo ý muốn của người sử dụng JWT. Tuy
nhiên để tránh trùng lặp, khóa nên được quy định ở trong IANA JSON Web Token Registry hoặc là 1 URI có chứa khơng gian tên khơng bị trùng lặp. Private: Claims tự định nghĩa (không được trùng với Reserved và Public),
được tạo ra để chia sẻ thông tin giữa 2 parties đã thỏa thuận và thống nhất trước đó.
1.4.2.3 Signature
Chữ ký Signature trong JWT là một chuỗi được mã hóa bởi header, payload cùng với một chuỗi bí mật theo ngun tắc sau:
Hình 1. 12: Hình ảnh ví dụ của Signature
Do bản thân Signature đã bao gồm cả header và payload nên Signature có thể dùng để kiểm tra tính tồn vẹn của dữ liệu khi truyền tải.
1.4.3 Khi nào thì dùng JWT?
Authentication: Tình huống thường gặp nhất, khi user logged in, mỗi request tiếp đó đều kèm theo chuỗi token JWT, cho phép người dùng có thể truy cập đường dẫn, dịch vụ và tài nguyên được phép ứng với token đó. Single Sign On cũng là một chức năng có sử dụng JWT một cách rộng rãi, bởi vì chuỗi JWT có kích thước đủ nhỏ để đính kèm trong request và sử dụng ở nhiều hệ thống thuộc các domain khác nhau.
Information Exchange: JSON Web Token cũng là một cách hữu hiệu và bảo mật để trao đổi thông tin giữa nhiều ứng dụng, bởi vì JWT phải được ký (bằng cặp public / private key), bạn có thể chắc rằng người gửi chính là người mà họ nói rằng họ là (nói tóm tắt hơn là khơng hoặc khó để mạo danh bằng JWT), ngồi ra, chữ ký cũng được tính toán dựa trên nội dung của header và nội dung payload, nhờ đó, bạn có thể xác thực được nội dung là nguyên bản, chưa được chỉnh sửa hoặc can thiệp. Tuy nhiên, một lưu ý hết sức quan trọng là do cấu trúc của JWT đơn giản nên JWT có thể dễ dàng bị decode, do vậy, bạn không nên dùng JWT để transfer các thông tin nhạy cảm.