Báo cáo bài tập lớn môn mật mã học cơ sở về JWT

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA CƠNG NGHỆ THÔNG TIN I
-----□□&□□-----

BÁO CÁO BÀI TẬP
MÔN: MẬT MÃ HỌC CƠ SỞ

ĐỀ TÀI: JWT
GIẢNG VIÊN:

TS. ĐỖ XUÂN CHỢ

NHÓM THỰC HIỆN: NHÓM 011
Phan Tuấn Anh

B18DCAT012

ssss

B17DCAT196

ssss

B18DCAT012

sss
ssss
ssss


Mục lục

Giới thiệu...........................................................................................................................................
Nội dung............................................................................................................................................
I. Khi nào nên dùng JSON Web Tokens?....................................................................................
II. JWT bảo vệ dữ liệu của chúng ta bằng cách nào?...................................................................
III. Cấu trúc..................................................................................................................................
IV. Các thuật toán mã hoá............................................................................................................
V. JSON Web Tokens hoạt động như thế nào?...........................................................................
VI. Các bước cơ bản để tạo JWT.................................................................................................
VII. Bài tập demo.........................................................................................................................


Giới thiệu
JSON Web Token (JWT) là một chuỗi mã hoá hay một tiêu chuẩn mở (RFC
7519) được sử dụng như một phương tiện đại diện nhỏ gọn nhằm xác minh thơng
tin an tồn giữa các bên Client-Server dưới dạng JSON object. Thơng tin này có
thể được xác minh và tin cậy vì nó được ký điện tử - digitally signed. JWT có thể
được ký bằng cách sử dụng một secret (với thuật toán HMAC) hoặc cặp
public/private key dùng chuẩn RSA hoặc ECDSA.
JSON là một dạng dữ liệu được sử dụng theo một quy luật chung nhất định
mà hầu hết các ngơn ngữ lập trình hiện nay đều có thể dễ dàng đọc và tìm hiểu. Nó
được xem là một tiêu chuẩn mở với mục đích sử dụng là trao đổi dữ liệu trong
website.
Token: Đây là một chữ ký điện tử được mã hoá thành các con số khác nhau
và các con số này tạo thành một dãy ấn tượng. Do được tạo dưới dạng OTP nên
loại mã số này chỉ được tạo ngẫu nhiên và sử dụng một lần cho từng lần giao dịch
khác nhau.

1

Nội dung
I. Khi nào nên dùng JSON Web Tokens?
Dưới đây là các lợi ích của việc sử dụng JWT:
● Uỷ quyền - Authorization: Đây là trường hợp nên sử dụng JWT. Khi
người dùng đã đăng nhập, mỗi request tiếp theo được gửi từ Client sẽ
bao gồm JWT, cho phép người dùng access vào routes, services và
resources được phép với token đó. Single Sign ON là tính năng trong
JWT được sử dụng rộng rãi hiện nay, vì chi phí thấp và dễ dàng sử
dụng trên các domains khác nhau.
● Trao đổi thông tin - Information Exchange: JSON Web Tokens là một
cách tốt để truyền thơng tin an tồn giữa các vên Client và Server. Vì
JWT có thể signed. Ví dụ, sử dụng các cặp public/private key, bạn có
thể biết ai là người gửi. Ngồi ra, vì signature được xác định dựa vào
header và payload, ta cũng có thể xác mình rằng nội dung chưa bị giả
mạo.

II. JWT bảo vệ dữ liệu của chúng ta bằng cách nào?
Một điều quan trọng về JWT là không ẩn hay làm mờ dữ liệu theo bất
kỳ cách nào. Lý do JWT được sử dụng là để chứng minh rằng dữ liệu được
gửi thực sự được tạo ra bởi một nguồn xác thực.
Dữ liệu bên trong JWT là mã hóa và được đánh dấu, hoặc khơng mã
hóa. Mục đích của việc mã hóa dữ liệu là chuyển đổi cấu trúc dữ liệu. Dữ
liệu đăng ký cho phép người nhận dữ liệu xác minh tích xác thực của nguồn
dữ liệu. Vì vậy, mã hóa và đánh dấu dữ liệu KHƠNG bảo mật dữ liệu. Mặc
khác, mục đích chính của mã hóa là bảo mật dữ liệu và ngăn chặn truy cập
trái phép

III. Cấu trúc

2


JSON Web Tokens bao gồm 3 phần (Header, Payload, Signature) được phân tách
bằng dấu `.`
JWT có dạng: xxxxx.yyyyy.zzzzz
Chuẩn format:
<base64-encoded header>.payload>.<HMACSHA256(base64-encoded signature)>
A. Header
Trong Header gồm có 2 phần: Loại mã token và thuật tốn được sử
dụng.
Ví dụ: Thuật tốn là HS256, loại mã token là JWT.

Sau đó JSON này được mã hoá Base64Url để tạo thành phần đầu tiên
của JWT.
B. Payload
Phần thứ 2 của token là payload, nó chứa các Claims. Claims thường
chứa các thuộc tính như :typically, thơng tin user và các dữ liệu bổ
sung. Có 3 loại claims: registered, public, và private claims.
● Registered claims: Đây là một tập hợp các claims được xác
định trước, không bắt buộc nhưng được khuyến nghị để có thể
cung cấp một tập hợp các claims hữu ích, có thể tương tác.
○ iss (issuer): tổ chức phát hành token (không bắt buộc)
○ sub (subject): chủ đề của token (không bắt buộc)
○ aud (audience): đối tượng sử dụng token (không bắt
buộc)
○ exp (expired time): thời điểm token sẽ hết hạn (không bắt
buộc)

3


○ nbf (not before time): token chưa hợp lên 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
Lưu ý là claim names thường chỉ chứa 3 ký tự.
● Public claims: Chúng có thể được xác định theo ý muốn của
những người sử dụng JWT. Để tránh xung đột, chúng ta phải
được xác định trong IANA JSON Web Token Registry hoặc
được định nghĩa là URI chứa namespace chống xung đột.
● Private claims: Đây là các claims tuỳ chỉnh được tạo để chia sẻ
thông tin giữa các bên đồng ý sử dụng chúng và khơng phải là
các registered hay public claims.
Ví dụ Payload có thể như sau:

Payload sau đó được mã hố Base64Url để tạo thành phần thứ 2 của
JSON Web Tokens.
Lưu ý: Đối với các signed tokens, thông tin này, mặc dù được bảo vệ
chống giả mạo nhưng mọi người đều có thể đọc được. Không được
đưa thông tin bảo mật các phần tử payload hoặc header của JWT trừ
khi được mã hoá.
C. Signature
Để tạo signature ta cần phải lấy header được mã hoá, payload được
mã hoá, một secret, thuật toán được chỉ định trong header và sign. Ví
dụ bạn dùng thuật toán HMAC SHA256, signature sẽ được tạo ra như
sau:

4


Signature được sử dụng để xác minh tin nhắn không bị thay đổi trên
đường truyền và trong trường hợp token được ký bằng private key,
nó cũng có thể xác mình người gửi JWT.

IV. Các thuật tốn mã hố
Có nhiều thuật toán mã hoá được sử dụng để tạo ra JWT, bao gồm các
thuật toán mã hoá đối xứng (symmetric) và khơng đối xứng (asymmetric).
Các thuật tốn phổ biến nhất là HMAC, RSA và ECDSA.
D. HMAC (Hash-based Message Authentication Code): là một thuật toán
mã hoá đối xứng sử dụng một khoá bí mật để ký và xác thực dữ liệu.
HMAC tính toán chữ ký bằng cách sử dụng một hàm băm (hash
function) và khố bí mật. Hàm băm được sử dụng phổ biến nhất là
SHA-256 hoặc SHA-512.
E. RSA (Rivest-Shamir-Adleman): là một thuật tốn mã hóa khơng đối
xứng, sử dụng để mã hố và khố bí mật được sử dụng để giải mã.
RSA được sử dụng trong JWT để tạo ra chữ ký bằng cách sử dụng
khố bí mật. Khố cơng khai được sử dụng để xác thực chữ ký.
F. ECDSA (Elliptic Curve Digital Signature Algorithm): Là một thuật
tốn mã hóa khơng đối xứng dựa trên đường cong Elliptic. ECDSA sử
dụng một cặp khố cơng khai và bí mật để tạo ra và xác thực chữ ký.
ECDSA có thể cung cấp độ bảo mật tương dương với RSA nhưng với
một kích thước khoá nhỏ hơn.

V. JSON Web Tokens hoạt động như thế nào?
Trong xác thực, khi người dùng đăng nhập thành công bằng thông tin đăng

5

nhập của họ, JSON Web Token sẽ được trả về. Vì token là thơng tin xác thực, cần
phải hết sức cẩn thận để ngăn chặn các vấn đề bảo mật. Nói chung, bạn khơng nên
giữ token lâu hơn u cầu.
Bạn cũng không nên lưu trữ dữ liệu nhạy cảm trên session trong bộ nhớ trình
duyệt do thiếu bảo mật.
Bất cứ khi nào người dùng muốn truy cập route hoặc resource được bảo vệ,
tác nhân người dùng nên gửi JWT, thêm Authorization trong header với nội dung
là Bearer + token. Nội dung của header sẽ trông như sau:
Authorization: Bearer <token>
Máy chủ server sẽ kiểm tra tính hợp lệ của JWT trong header mỗi khi nhận
request, nếu hợp lệ, người dùng sẽ được phép truy vấn cơ sở dữ liệu cho các hoạt
động nhất định có thể bị giảm, mặc dù điều này có thể khơng phải ln ln như
vậy.
Nếu Token được gửi trong Authorization header, chia sẻ tài nguyên nguồn
gốc chéo (Cross-Origin Resource Sharing - CORS) sẽ không thành vấn đề vì nó
khơng sử dụng cookie.
Sơ đồ sau đây cho thấy các JWT được lấy và sử dụng để truy cập API hoặc
resource:

1. Application hoặc client requests authorization đến authorization server. Điều
này được thực hiện thông qua một trong các luồng authorization khác nhau.
Ví dụ: Một ứng dụng web tuân thủ OpenID Connect điển hình sẽ đi qua /
oauth / uỷ quyền điểm cuối bằng cách sử dụng luồng mã authorization.
2. Khi authorization được cấp, authorization server sẽ trả lại access token cho
6


application.

3. Application sẽ sử dụng access token để truy cập vào resource (như API).
Lưu ý: Với các signed tokens, tất cả thông tin trong token vẫn được hiển thị cho
người dùng hoặc các bên khác, mặc dù họ không thể thay đổi thơng tin đó. Điều
này có nghĩa là bạn không nên đặt thông tin bảo mật trong token.

VI. Các bước cơ bản để tạo JWT
JWT là một chuỗi có định dạng: header.payload.signature.
G. Bước 1: Tạo HEADER.
Thành phần tiêu đề (header) dùng để khai báo chữ ký và thuật
toán mã hóa sẽ dùng cho token. Header là đối tượng JSON có định
dạng:

Trong đoạn mã JSON, giá trị của khóa “typ” xác định rằng đối
tượng là JWT và giá trị của khóa “alg” chỉ định thuật tốn băm nào
được sử dụng để tạo ra chữ ký (signature) cho JWT. Trong ví dụ của
mình, thuật tốn được sử dụng là HMAC-SHA256, thuật tốn băm sử
dụng secret key để tính tồn chữ ký (signature).
H. Bước 2: Tạo PAYLOAD
Phần thứ 2 của JWT là payload, nơi chứa các nội dung của
thông tin. Thông tin truyền đi có thể là mơ tả của một thực thể hoặc
cũng có thể là các thơng tin bổ sung thêm cho phần header. Nó được
chia làm 3 loại: Registered, public, và private.

7


Thành phần Payload của JWT là dữ liệu được lưu trữ bên trong
JWT (dữ liệu này còn được gọi là “các xác nhận quyền sở hữu” của
JWT). Trong ví dụ này, máy chủ xác thực tạo ra một JWT với thơng
tin người dùng được lưu trữ bên trong nó, đặc biệt là ID của người

dùng.

Trong ví dụ, ta chỉ đưa ra một xác nhận quyền sở hữu vào
payload. Bạn có thể đưa nhiều yêu cầu nếu bạn muốn. Có một số tiêu
chuẩn theo yêu cầu khác nhau cho payload JWT, chẳng hạn như “iss”,
“sub”, và “exp”. Các trường này có thể được sử dụng khi tạo JWT.
Lưu ý: Kích thước của dữ liệu sẽ ảnh hưởng đến kích thước
tổng thể của JWT, điều này thường không phải là vấn đề nhưng nếu
JWT quá lớn có thể ảnh hưởng tiêu cực đến hiệu suất và gây ra độ trễ.
I. Bước 3: Tạo Signature
Chữ ký (signature) được tính bằng cách sử dụng thuật toán sau:

Thuật toán này thực hiện bằng cách giải mã (header + payload).
Thuật tốn sau đó kết hợp các chuỗi được mã hóa kết quả cùng với
dấu chấm (.) ở giữa chúng. Trong đoạn mã, chuỗi nối này được gán
cho data. Chuỗi dữ liệu được băm bằng secret key sử dụng thuật toán
băm được chỉ định trong tiêu đề JWT. Kết quả dữ liệu băm được gán
cho hashedData. Dữ liệu băm này sau đó được mã hóa base64url để
tạo ra chữ ký (signature) JWT.
Trong ví dụ, cả header và payload được mã hóa Base64Url

8


Sau đó, áp dụng thuật tốn signature với secret key trên, header và
payload được mã hóa và ghép nối với nhau, chúng ta nhận được dữ
liệu được băm cung cấp cho signature. Trong TH của chúng ta, điều
này có nghĩa là áp dụng thuật toán HS256, với secret key là "secret"
trên chuỗi dữ liệu để nhận được chuỗi hashedData. Sau đó, thơng qua
base64url mã hóa chuỗi hashedData, chúng ta nhận được chữ ký của

JWT như sau:

J. Bước 4: Kết hợp 3 thành phần JWT với nhau.
Sau khi tạo cả 3 thành phần, chúng ta có thể tạo JWT. Cấu trúc
của JWT: HEADER.PAYLOAD.SIGNATURE, chúng ta chỉ cần kết
hợp các thành phần, với dấu chấm (.) để phân cách chúng. Chúng ta
sử dụng phiên bản được mã hóa base64 của header, payload và
signature được tạo ở trên.
VD: JWT Token
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMD
hmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ
.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM
K. Bước 5: Xác thực mã JWT.
Trong ví dụ về 3 thực thể đơn giản, chúng ta đang sử dụng JWT
được đăng ký bởi thuật tốn HS256, nơi chỉ có máy chủ xác thực và
máy chủ ứng dụng mới biết được mã secret. Máy chủ ứng dụng nhận
key secret từ máy chủ xác thực khi ứng dụng thiết lập quá trình xác
thực. Từ khi ứng dụng biết được secret key, khi người dùng thực hiện
các cuộc gọi API đính kèm JWT vào ứng dụng, ứng dụng có thể thực
hiện cùng một thuật tốn signature như trong Bước 3 trên JWT. Sau
đó, ứng dụng có thể xác minh rằng signature thu được từ việc thực

9


hiện băm của chính nó khớp với signature trên chính JWT (nghĩa là
khớp với signature JWT được tạo ra bởi máy chủ xác thực). Nếu
signature khớp với nhau, thì điều đó có nghĩa là JWT hợp lệ, cuộc gọi
API đến từ một nguồn xác thực. Nếu signature khơng khớp, thì có
nghĩa là JWT nhận được khơng hợp lệ, có thể là dấu hiệu của một tấn

công tiềm tàng trên ứng dụng. Vì vậy bằng cách xác minh JWT, ứng
dụng sẽ thêm một lớp tin cậy giữa chính nó và người dùng.

10


VII. Bài tập demo
Setup redis

Setup mariadb

Login API
11


Lấy JWT lưu trong redis

Decode JWT
12


Mã permission

13