Thứ Ba, Tháng Mười Hai 6, 2022
26 C
Ho Chi Minh City
spot_img

Giới thiệu Json Web Token (JWT) – GP Coder (Lập trình Java)

Must read

Openlivenft
Openlivenfthttps://openlivenft.info/
Trang tổng hợp thông tin nhanh - mới nhất về NFT, COIN, Metaverse, tài chính, crypto của OpenliveNFT
Authentication là phần không hề thiếu trong bất kể mạng lưới hệ thống nào. Phương pháp authentication đơn thuần và hay được sử dụng trong những ứng dụng web đó là user gửi thông tin username và password lên server. Sau khi server xác nhận thành công xuất sắc sẽ tạo ra một chuỗi session_id và lưu vào session hay database ở phía server. Sau đó, gửi session_id này về client và được client lưu trên cookie. Nhưng với những ứng dụng trên mobile và những ứng dụng web SPA ( Single Page Application ) thì cần có chính sách authentication tốt hơn khi mà tất cả chúng ta phải phong cách thiết kế những RESTful api ( stateless ) thì server không hề đảm nhiệm việc lưu trạng thái phiên thao tác của user. Một trong những giải pháp tốt để xử lý yếu tố này là sử dụng JSON Web Token ( JWT ) .

JSON Web Token ( JWT ) là gì ?

JSON Web Token (JWT) là 1 tiêu chuẩn mở (RFC 7519), định nghĩa cách thức truyền tin an toàn giữa các ứng dụng bằng một đối tượng JSON. Dữ liệu truyền đi sẽ được mã hóa và chứng thực, có thể được giải mã để lấy lại thông tin và đánh dấu tin cậy nhờ vào “chữ ký” của nó. Phần chữ ký của JWT sẽ được mã hóa lại bằng HMAC hoặc RSA.

JWT có 2 đặc điểm:

  • Gọn nhẹ (compact): JWT có thể được truyền đi thông qua URL, hoặc qua giao thức POST, hay gán vào bên trong phần HTTP Header. Kích thước nhỏ hơn ứng với công việc truyền tải sẽ nhanh hơn. Dưới đây là cách thức truyền token vào trong HTTP Header sử dụng Bearer Schema:

Authorization: Bearer

  • Tự đóng gói (self-contained): Payload của JWT đã chứa các thông tin cần thiết về user (thay vì phải truy vấn cơ sở dữ liệu nhiều lần).

JSON Web Token ( JWT ) gồm những thành phần nào ?

JWT bao gồm 3 phần, ngăn cách nhau bởi dấu “.“, gồm:

  • Header
  • Payload
  • Signature

Chuỗi JWT: header.payload.signature

Ví dụ chuỗi JWT :

Trong đó :– Header : là Base64URL encoded của json .

– Payload : là Base64URL encoded của json .

– Signature : là tác dụng của function Algorithm :

Gồm 2 phần : type của token, giá tri là JWT, và phương pháp mã hóa ( HMAC SHA256 hay RSA ) .JSON object này sau đó được mã hóa Base64URL .

Payload

Payload chức những thành phần gọi là claim. Các claim này chứa những thông tin về đối tượng người dùng ( thường là user ), và những meta data của token. Server sẽ dùng những thông tin từ những claim này để hoàn toàn có thể triển khai authentication. Có 3 loại claim : reserved, public và private .

Reserved claim

Là những thông tin đã được pháp luật ở trong IANA JSON Web Token Claims registry. Các claim này là không bắt buộc phải có trong token, nhưng hoàn toàn có thể phân phối những thông tin có ích. Các claim này chỉ gồm 3 ký tự vì mục tiêu giảm size của Token .

  • iss (issuer): tổ chức phát hành token.
  • sub (subject): chủ đề của token.
  • aud (audience): đối tượng sử dụng token.
  • exp (expired time): thời điểm token sẽ hết hạn.
  • nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này.
  • iat (issued at): thời điểm token được phát hành, tính theo UNIX time.
  • jti: JWT ID.

Public claim

Là những claim được định nghĩa 1 cách công khai minh bạch bởi những bên sử dụng JWT. Chúng nên được pháp luật ở trong IANA JSON Web Token Registry hoặc là 1 URI có chứa khoảng trống tên không bị trùng lặp. Ví dụ :

{
"https://openlivenft.info/jwt_clams/user_role" : "admin"
}

Private claim

Là những claim tự định nghĩa và chỉ những thành phần tương quan của mạng lưới hệ thống hiểu được. Ví dụ :

{
"email":"[email protected]",
"name":"gpcoder"
}

Signature

Signature được tạo ra bằng cách dùng chiêu thức mã hóa được chỉ định ở header để mã hóa nội dung encode của header, payload, cùng với chuỗi khóa bí hiểm .Phương thức mã hóa hoàn toàn có thể là HMAC hay RSA :

  • HMAC: đối tượng khởi tạo JWT (token issuer) và đầu nhận JWT (token verifier) sử dụng chung 1 mã bí mật để mã hóa và kiểm tra.
  • RSA: sử dụng 1 cặp key, đối tượng khởi tạo JWT sử dụng Private Key để mã hóa, đầu nhận JWT sử dụng Public Key để kiểm tra.

Như vậy với HMAC, cả 2 phía đều phải san sẻ mã bí hiểm cho nhau, và đầu nhận JWT trọn vẹn hoàn toàn có thể khởi tạo 1 mã JWT khác hợp lệ dựa trên mã bí hiểm đó. Còn với RSA, đầu nhận sử dụng Public Key để kiểm tra nhưng không hề khởi tạo được 1 JWT mới dựa trên key đó. Vì vậy mã hóa sử dụng RSA giúp cho việc bảo mật thông tin chữ ký tốt hơn khi cần san sẻ JWT với nhiều đối tượng người tiêu dùng khác nhau .Ví dụ : nếu header chỉ định dùng thuật toán mã hóa HMAC SHA256, và phía server dùng chuỗi khóa bị mật là ‘ secret ’ thì signature sẽ được tạo ra như sau :

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload), "secret"
)

Signature được dùng để xác nhận là token JWT là đúng và nội dung của token đã không được đổi khác .

JSON Web Token ( JWT ) hoạt động giải trí như thế nào ?

  • Application hoặc client gửi thông tin chứng thực lên server (có thể là username/ password).
  • Khi đã chứng thực thành công, authorization server sẽ trả về một access token (JWT) cho client.
  • Phía Client sẽ gửi token này kèm theo request để truy cập resource. Thông thường token được gửi trong header: Authorization: Bearer

Khi nào nên dùng JSON Web Token ?

Dưới đây là một vài ngữ cảnh thích hợp với JWT :

  • Chứng thực: Đây là kịch bản phổ biến nhất cho việc sử dụng JWT. Một khi người dùng đã đăng nhập vào hệ thống thì những request tiếp theo từ phía người dùng sẽ chứa thêm mã JWT, cho phép người dùng quyền truy cập vào các đường dẫn, dịch vụ, và tài nguyên mà cần phải có sự cho phép nếu có mã Token đó. Phương pháp này không bị ảnh hưởng bởi Cross-Origin Resource Sharing (CORS) do nó không sử dụng cookie.
  • Trao đổi thông tin: JWT là 1 cách thức không tồi để truyền tin an toàn giữa các thành viên với nhau, nhờ vào phần “chữ ký” của nó. Phía người nhận có thể biết được người gửi là ai thông qua phần chữ ký. Ngoài ra, chữ ký được tạo ra bằng việc kết hợp cả phần header, payload lại nên thông qua đó ta có thể xác nhận được chữ ký có bị giả mạo hay không.

Tại sao sử dụng JWT ?

  • Performance : JWT gọn nhẹ và đơn giản. Chuỗi token sinh ra ngắn gọn đủ để chứa các thông tin cần thiết (nếu session thì cần đọc ở storage hoặc database). Và bất kỳ ai cũng có thể dễ dàng hiểu, áp dụng được JWT
  • Stateless: Rất phù hợp để áp dụng xây dựng stateless API, bởi token đã chứa đầy đủ các thông tin cần thiết để thực thi authentication.
  • Việc apply ở phía client rất đơn giản, cho dù nền tảng web hay mobile.
  • Dễ dàng mở rộng server hơn. Điều này là nhờ tính stateless của JWT, server không cần phải lưu session state, nên trong trường hợp phía server sử dụng cơ chế load balancing, bất kỳ máy server nào cũng có thể handle request và vẫn có được state của user thay vì chỉ server mà user đã login.
  • Security: Vì JWT không sử dụng cookie nên ta không cần phải lo về vấn đề CSRF. Nhưng JWT tốt nhất cần được sử dụng kèm với HTTPS.
  • Reusable: Chúng ta có thể có nhiều system chạy các nền tảng khác nhau có thể cùng sử dụng 1 JWT để thực hiện authenticate user. Điều này là khó hoặc không thể nếu state được lưu giữ phía server.

Tài liệu tham khảo:

4.6

Nếu bạn thấy hay thì hãy chia sẻ bài viết cho mọi người nhé!

Shares

Bình luận

phản hồi

Source: https://openlivenft.info
Category : TIN COIN

Đánh giá bài post
- Advertisement -spot_img

More articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisement -spot_img

Latest article

Ethereum là gì? | OpenliveNFT