--- title: "JWT là gì? Các thành phần chính trong JWT" description: "JWT (JSON Web Token) là một tiêu chuẩn mã nguồn mở (RFC 7519) dùng để truyền tải thông tin an toàn, gọn nhẹ và khép kín giữa các bên tham gia dưới dạng JSON" canonical: "https://200lab.io/blog/jwt-la-gi" published: "2023-08-18T04:14:20Z" updated: "2026-08-21T07:18:00Z" authors: ["Lương Việt Hải"] tags: ["Backend", "Basic"] reading_minutes: 8 access: "public" --- Với thời đại mobile app, web app trở nên phổ biến, việc sử dụng _authenticate_ (xác thực) bằng _**JWT**_ ([JSON Web Token]())  đã trở nên phổ biến và được triển khai rất rộng rãi. Dù bạn là lập trình viên _[backend]()_ hay _frontend_, việc hiểu biết về _JWT_ và cách thức hoạt động cũng như chức năng cốt lõi là điều cần thiết để có thể sử dụng và triển khai đúng cách và tận dụng tối đa khả năng của nó. Trong bài viết này, chúng ta sẽ cùng tìm hiểu chi tiết đến _JWT_, các khái niệm, thành phần trong đó và một số ứng dụng thực tiễn của _JWT_. ## 1. JWT (JSON Web Token) là gì JWT (**J**SON **W**eb **T**oken) là một tiêu chuẩn mã nguồn mở ([RFC 7519]()) dùng để truyền tải thông tin an toàn, gọn nhẹ và khép kín giữa các bên tham gia dưới format JSON. Thông tin được chia sẻ trong _JWT_ được xác thực và tin cậy thông qua chữ ký số (_Digital signature_). Các bên sẽ sử dụng _mật mã khoá đối xứng_ (cùng với _HMAC_) hoặc dùng_ mật mã khoá công khai_ (cùng _public_ và _private key_) để thực hiện ký số (_signed_). > JSON Web Token (JWT) is a **compact**, **URL-safe means of representing claims** to be transferred between **two parties**. > > Nguồn: [https://datatracker.ietf.org/doc/html/rfc7519]() ## 2. Cấu tạo của JWT _JWT_ gồm 3 phần chính, và phần tách nhau bằng một dấu chấm (`.`): - _Header_ - _Payload_ - _Signature_ Vì vậy, _JWT_ sẽ có dạng như sau : ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ``` _Ví dụ cấu trúc của một JWT_ ![Thành phần trong JWT](https://assets.200lab.io/images/2024/12/05/screen-shot-2023-08-17-at-18-07-23-eb0482e50c4819b5deaf.webp) Chúng ta cùng đi chi tiết để từng thành phần của _JWT_ ### 2.1 Header Header thông thường sẽ bao gồm 2 thành phần, gồm : Kiểu _token_, mà với trường hợp này luôn luôn là _JWT_, và thuật toán mã hoá được sử dụng, ví dụ như _HMAC_ hoặc _RSA_. Do đó, _Header_ của _JWT_ sẽ có dạng như sau. ``` { "alg": "HS256", "typ": "JWT" } ``` Sau đó, đoạn này sẽ được _encoding_ (_base64Encode_) và trở thành chuỗi đầu tiên trong 3 chuỗi _JWT_. ### 2.2 Payload _Payload_ trong JWT chứa các _claims_. Trong lĩnh vực an toàn thông tin, _claims_ đề cập đến sự tuyên bố quyền truy cập hoặc quyền sử dụng tài nguyên. _Claims_ là tập hợp các thông tin đại diện cho một thực thể (_object_) (ví dụ : user\_id) và một số thông tin đi kèm. _Claims_ sẽ có dạng _Key - Value_. Do đó, chúng ta có thể hiểu rằng, _claims_ ám chỉ việc yêu cầu truy xuất tài nguyên cho _object_ tương ứng. Có 3 kiểu _claims_, bao gồm _registered_, _public_, and _private_ _claims_. #### 2.2.1 Registered Claims _Registered Claims_ là các thành phần được xác định trước của _claims_. Thành phần này mặc dù không bắt buộc, nhưng là thành phần nên có để cung cấp một số chức năng và thông tin hữu ích. Một số r_egistered claims _bao gồm : - `iss` (issuer): Tổ chức, đơn vị cung cấp, phát hành _JWT_. - `sub` (subject): Chủ thể của _JWT_, xác định rằng đây là người sở hữu hoặc có quyền truy cập các _resource_ (tài nguyên). - `aud` (audience): Được hiểu là người nhận thông tin, và có thể xác thực tính hợp lệ của _JWT_. - `exp` (expiration time): Thời hạn của _JWT_, vượt quá thời gian này, _JWT_ được coi là không hợp lệ #### 2.2.2 Public Claims _Public claims_ là các thành phần được xác định bởi người sử dụng _JWT_, được sử dụng rộng rãi trong _JWT_. Mặc dù việc sử dụng _public claims_ không phải là bắt buộc, tuy nhiên để tránh xảy ra xung đột,_ public claims_ _name_ được xác định theo danh sách dưới đây: Claim Name Claim Description iss Issuer sub Subject aud Audience exp Expiration Time nbf Not Before iat Issued At jti JWT ID name Full name given\_name Given name(s) or first name(s) family\_name Surname(s) or last name(s) middle\_name Middle name(s) nickname Casual name preferred\_username Shorthand name by which the End-User wishes to be referred to profile Profile page URL picture Profile picture URL Danh sách các [public claims]() Một số _public claims_ điển hình : - `name, given_name, family_name, middle_name`: Thông tin tên nói chung của user - `email`: Thông tin email của user. - `locale` : Địa chỉ của user. - `profile, picture` : Thông tin của trang web gửi đến. #### 2.2.3 Private Claims Các bên sử dụng _JWT_ có thể sẽ cần sử dụng đến _claims_ không phải là _Registered Claims,_ cũng không được định nghĩa trước như_ Public Claims. _Đây là phần thông tin mà các bên tự thoả thuận với nhau, không có tài liệu hay tiêu chuẩn nào dành cho _private claims._ **Lưu ý:** Tên _claims_ chỉ nên dài ba ký tự vì _JWT_ hướng tới sự nhỏ gọn. ### 2.3 Signature _Signature_ là phần cuối cùng của _JWT_, có chức năng xác thực danh tính người gửi. Để tạo ra một _signature_ chính xác, ta cần _encode_ phần _header_, phần _payload_, chọn _cryptography _(mật mã khoá) thích hợp đã được xác định ở _header _kèm_ secret key_ và thực hiện _sign. _ Ví dụ, nếu chúng ta lựa chọn hàm _HMACSHA256_,  _function_ thực hiện _sign_ sẽ có dạng như sau: ``` HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) ``` Cả bên gửi và bên nhận _JWT_ đều sẽ xử dụng hàm này để xác định phần _signature_, nếu thông tin này của cả 2 bên khác nhau, _JWT_ này được coi là không hợp lệ. **Lưu ý:** Chỉ có người có _secret key_ mới có thể _sign_ được một _signature_ phù hợp. Do đó, danh tính của bên gửi được đảm bảo nhờ có _signature._ ## 3. Lý do sử dụng JWT - **Authentication** (Xác thực): JWT được sử dụng để xác thực người dùng trước khi họ truy cập đến tài nguyên trên server. - **Authorization** (Uỷ quyền): Khi người dùng đăng nhập thành công, application có thể truy cập vào các tài nguyên thay mặt người dùng đó. Các ứng dụng đăng nhập một lần (_Single Sign-On SSO_) sử dụng _JWT_ thường xuyên vì tính nhỏ gọn và dễ dàng triển khai trên nhiều domain. - **Trao đổi thông tin an toàn**: _JWT_ được coi là một cách trao đổi thông tin an toàn vì thông tin đã được _signed_ trước khi gửi đi. ## 4. Ưu điểm của JWT - **Gọn nhẹ**:** **_JWT_ nhỏ gọn, chi phí truyền tải thấp giúp tăng hiệu suốt của các ứng dụng. - **Bảo mật**: _JWT_ sử dụng các _mật mã khoá _để tiến hành xác thực người danh tính người dùng. Ngoài ra, cấu trúc của _JWT_ cho phép chống giả mạo nên thông tin được đảm bảo an toan trong quá trình trao đổi. - **Phổ thông**: _JWT_ được sử dụng dựa trên _JSON_, là một dạng dữ liệu phổ biến, có thể sử dụng ở hầu hết các ngôn ngữ lập trình. Ngoài ra, triển khai _JWT_ tương đối dễ dàng và tích hợp được với nhiều thiết bị, vì _JWT_ đã tương đối phổ biến. ## 5. Khuyết điểm của JWT - **Kích thước**:** **Mặc dù trong tài liệu không ghi cụ thể giới hạn, nhưng do được truyền trên _HTTP Header_, vì thế, _JWT_ có giới hạn tương đương với _HTTP Header_ (khoảng 8KB). - **Rủi ro bảo mật**: Khi sử dụng _JWT_ không đúng cách, ví dụ như không kiểm tra tính hợp lệ của _signature_, không kiểm tra _expire time_, kẻ tấn công có thể lợi dụng sơ hở để truy cập vào các thông tin trái phép. Ngoài ra, việc để thời gian hết hạn của _JWT_ quá dài cũng có thể tạo ra kẽ hở tương tự. ## 6. Một số ứng dụng JWT - **Single Sign-On (SSO)**:** **_JWT_ có thể được sử dụng để cung cấp _single sign-on_ cho người dùng. Điều này cho phép họ đăng nhập vào nhiều ứng dụng chỉ với một tài khoản duy nhất. - **API Authorization**: _JWT_ thường được sử dụng để phân quyền cho người dùng đến những tài nguyên cụ thể, từ những _claims _chứa_ _trong JWT đó. - **User** **Authentication:** _JWT_ cung cấp khả năng xác thực người dùng và cấp quyền cho họ truy cập vào các tài nguyên mong muốn trong hệ thống. - **Microservices Communication: **_JWT_ còn có thể sử dụng cho việc giao tiếp giữa các _service_ nhỏ trong hệ thống _microservices_. ## 7. Kết luận WT thường được sử dụng trong các hệ thống xác thực và ủy quyền, đặc biệt là trong các ứng dụng web và dịch vụ API, nhờ vào tính gọn nhẹ và khả năng tích hợp dễ dàng với các hệ thống khác nhau. Tuy nhiên, việc triển khai JWT cũng cần được thực hiện cẩn thận để tránh các lỗ hổng bảo mật, đảm bảo rằng mã hóa và ký số được thực hiện đúng cách, các token được quản lý hiệu quả. Các bài viết liên quan tại blog 200Lab: - [Proxy và Reverse Proxy là gì? Hướng dẫn sử dụng Proxy]() - [NestJS: Giải Pháp Toàn Diện Cho Ứng Dụng Server-Side]() - [Hướng dẫn sử dụng JWT. Các lỗi sai thường thấy trong JWT]() - [NextJS là gì? Kiến thức NextJS cơ bản bạn cần biết]()