Session Vs JWT: Những Khác Biệt Bạn Có Thể Chưa Biết!

0:00 Today, we're diving into the  world of web authentication.

0:03 We’ll explore the two most common approaches:

0:05 session-based authentication  and JSON Web Tokens, or JWTs.

0:10 We’ll walk through the flow of each  mechanism and discuss their pros and cons.

0:14 By the end, you'll have a clear  understanding of when to use each one.

0:17 Let's get started!

0:19 First, let's walk through the flow  of session-based authentication.

0:22 The user sends their login  credentials to the server.

0:25 The server verifies these credentials.

0:27 If they're valid, it creates a new session.

0:30 The server then stores the session data, typically  in a database or in-memory cache like Redis.

0:35 This data might include the user ID,  session expiration time, and other metadata.

0:40 The server sends back a response with a unique  session ID, usually in the form of a cookie.

0:45 On subsequent requests, the client automatically  sends the session ID cookie with each request.

0:51 The server takes the session ID, looks  up the corresponding session data in its

0:55 session store, and uses that data to  authenticate and process the request.

1:00 The key point is that with  session-based authentication,

1:03 the server is responsible for  creating and storing the session data.

1:07 It then uses the session ID as a key to  retrieve this data on future requests.

1:12 One advantage of sessions is that  revoking a session is straightforward.

1:16 Since the session data is stored on the server,

1:19 the server can simply delete or  invalidate the session at any time.

1:23 However, in a distributed system where  your application runs on multiple servers,

1:28 all those servers need access  to the same session data.

1:31 This is typically achieved by using  a centralized session store that all

1:35 servers can access, like Redis  or a distributed SQL database.

1:39 While this works well, it does add some  complexity and potential latency to each

1:43 request, as the server needs to make  a separate trip to the session store.

1:48 Now, let's look at the flow  of JWT-based authentication.

1:51 First, the user sends their  login credentials to the server.

1:54 The server verifies these credentials.

1:56 If they're valid, it generates a JWT.

1:59 The server signs the JWT with a secret key.

2:01 This signature ensures the integrity  of the token, preventing tampering.

2:06 The server then sends back the JWT to the  client, typically in the response body.

2:10 The client stores the JWT, usually  in local storage or a cookie.

2:14 On subsequent requests, the client  sends the JWT in the request headers.

2:19 The server verifies the JWT signature.

2:21 If it's valid, the server  trusts the data in the token

2:24 and uses it for authentication and authorization.

2:28 The critical difference here is that with JWTs,  the server doesn't store any session state.

2:33 All the necessary data is contained within the  token itself, which is stored on the client.

2:38 This makes JWTs stateless.

2:40 For signing JWTs, there are  several algorithms available,

2:43 with HMAC, RSA , and ECDSA being the most common.

2:47 HMAC is a symmetric signing method,

2:50 which means the same secret key is  used to sign and verify the token.

2:54 This is simpler and more efficient, but  it requires sharing the secret key with

2:58 any service that needs to verify the  token, which can be a security concern.

3:02 RSA and ECDSA, on the other hand,  are asymmetric signing methods.

3:07 They use a private key to sign the  token and a public key to verify it.

3:11 This allows for a more secure architecture  where the private key is kept secret and

3:16 only used for signing, while any service  can verify the token using the public key.

3:21 However, this adds some complexity and  computational overhead compared to HMAC.

3:26 The choice of signing algorithm depends on your  security requirements and system architecture.

3:32 If you have a monolithic application or  trust all the services in your system,

3:36 HMAC might be sufficient.

3:38 But if you have a microservice  architecture or need to share JWTs

3:42 with untrusted third-party services, RSA  or ECDSA provide a more secure solution.

3:49 One challenge with JWTs is  handling token expiration.

3:52 If a token is stolen, it can  be used until it expires.

3:56 To mitigate this, you can use refresh tokens  in combination with short-lived access tokens.

4:01 The access token is the actual JWT  used for authentication on each

4:05 request. It has a short expiration  time, typically around 15 minutes.

4:10 The refresh token, on the other hand,

4:12 has a much longer expiration time,  perhaps several days or weeks.

4:16 When the access token expires, instead  of requiring the user to log in again,

4:20 the client can send the refresh token to  a special token endpoint on the server.

4:25 The server checks if the refresh  token is valid and hasn't been

4:28 revoked. If everything checks out,  the server issues a new access token.

4:33 This process happens behind the scenes,  without requiring interaction from the user.

4:38 This approach strikes a balance  between security and user experience.

4:41 The short-lived access tokens limit the window  of potential misuse if a token is stolen,

4:47 while the long-lived refresh tokens  allow users to remain authenticated

4:51 for an extended period without  needing to log in repeatedly.

4:55 It's important to note that the refresh  token is only sent when the access

4:59 token has expired, not on every request.

5:02 The access token is sent on every  request that requires authentication.

5:06 So, when should you use session-based  authentication, and when are JWTs a better choice?

5:11 Session-based authentication is a good fit when  you need the ability to revoke sessions instantly.

5:17 If a user reports their account as compromised,

5:19 you can immediately invalidate  their session on the server side.

5:23 Sessions are also a good choice if you already  have a centralized data store for other purposes.

5:28 In this case, you can leverage that existing  infrastructure for session storage as well.

5:33 However, it's important to keep in mind  that using a centralized session store does

5:37 add some latency to each request, as the server  needs to fetch the session data from the store.

5:43 Finally, sessions keep sensitive data on the  server, which can be a security advantage.

5:48 On the other hand, JWTs are a great choice  when you need a stateless architecture.

5:52 Because JWTs store all the  necessary data in the token itself,

5:56 your server doesn't need to keep track  of sessions in memory or in a database.

6:00 This makes it much easier to scale your  application horizontally across multiple servers.

6:05 JWTs are also useful when you need to share  authentication data with other services.

6:10 For instance, in a microservice architecture,

6:13 a JWT generated by the authentication  service can be verified and trusted by

6:17 other services without needing to contact  the authentication service on each request.

6:22 If you do choose JWTs,

6:24 consider implementing refresh tokens to  balance security and user experience.

6:28 Refresh tokens allow you to use short-lived access  tokens to limit the window of potential misuse,

6:34 while still allowing users to remain  authenticated for an extended period.

6:38 Ultimately, the choice depends on the specific  needs and architecture of your application.

6:44 If you like our videos, you might like  our system design newsletter as well.

6:48 It cover topics and trends  in large scale system design.

6:51 Trusted by 500,000 readers.

6:54 Subscribe at blog.bytebytego.com.

0:00 Hôm nay, chúng ta sẽ đi sâu vào thế giới xác thực web. Chúng ta sẽ khám phá hai phương pháp phổ biến nhất: xác thực dựa trên phiên và JSON Web Tokens, hay còn gọi là JWT. Chúng ta sẽ xem xét quy trình hoạt động của từng cơ chế và thảo luận về ưu, nhược điểm của chúng. Đến cuối video này, bạn sẽ hiểu rõ khi nào nên sử dụng phương pháp nào. Bắt đầu thôi!

0:19 Đầu tiên, hãy cùng tìm hiểu quy trình xác thực dựa trên phiên. Người dùng gửi thông tin đăng nhập của họ đến máy chủ. Máy chủ xác minh thông tin này. Nếu thông tin hợp lệ, nó sẽ tạo ra một phiên mới. Sau đó, máy chủ lưu trữ dữ liệu phiên, thường là trong cơ sở dữ liệu hoặc bộ nhớ cache như Redis. Dữ liệu này có thể bao gồm ID người dùng, thời gian hết hạn phiên và các thông tin khác. Máy chủ gửi lại phản hồi với một ID phiên duy nhất, thường ở dạng cookie. Trong các yêu cầu tiếp theo, trình duyệt sẽ tự động gửi cookie ID phiên này với mỗi yêu cầu. Máy chủ nhận ID phiên, tìm kiếm dữ liệu phiên tương ứng trong kho lưu trữ phiên của nó và sử dụng dữ liệu đó để xác thực và xử lý yêu cầu. Điểm quan trọng là với xác thực dựa trên phiên, máy chủ chịu trách nhiệm tạo và lưu trữ dữ liệu phiên. Sau đó, nó sử dụng ID phiên như một chìa khóa để truy xuất dữ liệu này trong các yêu cầu sau.

1:12 Một ưu điểm của phiên là việc thu hồi phiên rất đơn giản. Vì dữ liệu phiên được lưu trữ trên máy chủ, máy chủ có thể dễ dàng xóa hoặc vô hiệu hóa phiên bất kỳ lúc nào. Tuy nhiên, trong một hệ thống phân tán, nơi ứng dụng của bạn chạy trên nhiều máy chủ, tất cả các máy chủ đó cần truy cập vào cùng một dữ liệu phiên. Điều này thường được thực hiện bằng cách sử dụng một kho lưu trữ phiên tập trung mà tất cả các máy chủ có thể truy cập, ví dụ như Redis hoặc cơ sở dữ liệu SQL phân tán. Mặc dù cách này hoạt động tốt, nhưng nó làm tăng thêm một chút phức tạp và độ trễ tiềm ẩn cho mỗi yêu cầu, vì máy chủ cần thực hiện một bước riêng để truy cập vào kho lưu trữ phiên.

1:48 Bây giờ, hãy xem quy trình xác thực dựa trên JWT. Đầu tiên, người dùng gửi thông tin đăng nhập của họ đến máy chủ. Máy chủ xác minh thông tin này. Nếu thông tin hợp lệ, nó sẽ tạo ra một JWT. Máy chủ ký JWT bằng một khóa bí mật. Chữ ký này đảm bảo tính toàn vẹn của mã thông báo, ngăn chặn việc giả mạo. Sau đó, máy chủ gửi lại JWT cho trình duyệt, thường là trong phần thân phản hồi. Trình duyệt lưu trữ JWT, thường là trong bộ nhớ cục bộ hoặc cookie. Trong các yêu cầu tiếp theo, trình duyệt gửi JWT trong tiêu đề yêu cầu. Máy chủ xác minh chữ ký JWT. Nếu nó hợp lệ, máy chủ tin tưởng dữ liệu trong mã thông báo và sử dụng nó để xác thực và ủy quyền. Sự khác biệt quan trọng ở đây là với JWT, máy chủ không lưu trữ bất kỳ trạng thái phiên nào. Tất cả dữ liệu cần thiết đều nằm trong chính mã thông báo, được lưu trữ trên trình duyệt. Điều này làm cho JWT trở nên stateless (không trạng thái).

2:40 Để ký JWT, có một số thuật toán có sẵn, trong đó HMAC, RSA và ECDSA là phổ biến nhất. HMAC là một phương pháp ký đối xứng, có nghĩa là cùng một khóa bí mật được sử dụng để ký và xác minh mã thông báo. Điều này đơn giản và hiệu quả hơn, nhưng nó yêu cầu chia sẻ khóa bí mật với bất kỳ dịch vụ nào cần xác minh mã thông báo, điều này có thể là một vấn đề về bảo mật. Mặt khác, RSA và ECDSA là các phương pháp ký bất đối xứng. Chúng sử dụng khóa riêng tư để ký mã thông báo và khóa công khai để xác minh nó. Điều này cho phép một kiến trúc an toàn hơn, nơi khóa riêng tư được giữ bí mật và chỉ được sử dụng để ký, trong khi bất kỳ dịch vụ nào cũng có thể xác minh mã thông báo bằng khóa công khai. Tuy nhiên, điều này làm tăng thêm một chút phức tạp và chi phí tính toán so với HMAC. Việc lựa chọn thuật toán ký phụ thuộc vào yêu cầu bảo mật và kiến trúc hệ thống của bạn. Nếu bạn có một ứng dụng nguyên khối hoặc tin tưởng tất cả các dịch vụ trong hệ thống của mình, HMAC có thể là đủ. Nhưng nếu bạn có một kiến trúc microservice hoặc cần chia sẻ JWT với các dịch vụ bên thứ ba không đáng tin cậy, RSA hoặc ECDSA cung cấp một giải pháp an toàn hơn.

3:49 Một thách thức với JWT là xử lý thời gian hết hạn của mã thông báo. Nếu một mã thông báo bị đánh cắp, nó có thể được sử dụng cho đến khi hết hạn. Để giảm thiểu điều này, bạn có thể sử dụng mã thông báo làm mới (refresh token) kết hợp với mã thông báo truy cập (access token) có thời gian tồn tại ngắn. Mã thông báo truy cập là JWT thực tế được sử dụng để xác thực trên mỗi yêu cầu. Nó có thời gian hết hạn ngắn, thường là khoảng 15 phút. Mặt khác, mã thông báo làm mới có thời gian hết hạn dài hơn nhiều, có thể là vài ngày hoặc vài tuần. Khi mã thông báo truy cập hết hạn, thay vì yêu cầu người dùng đăng nhập lại, trình duyệt có thể gửi mã thông báo làm mới đến một điểm cuối mã thông báo đặc biệt trên máy chủ. Máy chủ kiểm tra xem mã thông báo làm mới có hợp lệ và chưa bị thu hồi hay không. Nếu mọi thứ đều ổn, máy chủ sẽ cấp một mã thông báo truy cập mới. Quá trình này diễn ra ở chế độ nền, mà không yêu cầu tương tác từ người dùng. Cách tiếp cận này tạo ra sự cân bằng giữa bảo mật và trải nghiệm người dùng. Các mã thông báo truy cập có thời gian tồn tại ngắn giới hạn phạm vi lạm dụng tiềm ẩn nếu một mã thông báo bị đánh cắp.

4:47 trong khi các mã thông báo làm mới có thời gian tồn tại dài cho phép người dùng duy trì trạng thái đăng nhập trong một khoảng thời gian dài mà không cần phải đăng nhập nhiều lần. Điều quan trọng cần lưu ý là mã thông báo làm mới chỉ được gửi khi mã thông báo truy cập đã hết hạn, không phải trên mọi yêu cầu. Mã thông báo truy cập mới là thứ được gửi trên mọi yêu cầu cần xác thực.

5:06 Vậy, khi nào bạn nên sử dụng xác thực dựa trên phiên và khi nào JWT là một lựa chọn tốt hơn? Xác thực dựa trên phiên là một lựa chọn tốt khi bạn cần khả năng thu hồi phiên ngay lập tức. Nếu người dùng báo cáo tài khoản của họ bị xâm phạm, bạn có thể ngay lập tức vô hiệu hóa phiên của họ ở phía máy chủ. Phiên cũng là một lựa chọn tốt nếu bạn đã có một kho lưu trữ dữ liệu tập trung cho các mục đích khác. Trong trường hợp này, bạn có thể tận dụng cơ sở hạ tầng hiện có đó để lưu trữ phiên. Tuy nhiên, điều quan trọng cần lưu ý là việc sử dụng kho lưu trữ phiên tập trung sẽ làm tăng thêm một chút độ trễ cho mỗi yêu cầu, vì máy chủ cần tìm nạp dữ liệu phiên từ kho lưu trữ. Cuối cùng, phiên giữ dữ liệu nhạy cảm trên máy chủ, điều này có thể là một lợi thế về mặt bảo mật.

5:48 Mặt khác, JWT là một lựa chọn tuyệt vời khi bạn cần một kiến trúc stateless (phi trạng thái). Vì JWT lưu trữ tất cả dữ liệu cần thiết trong chính mã thông báo, máy chủ của bạn không cần phải theo dõi các phiên trong bộ nhớ hoặc trong cơ sở dữ liệu. Điều này giúp bạn dễ dàng mở rộng ứng dụng của mình theo chiều ngang trên nhiều máy chủ hơn. JWT cũng hữu ích khi bạn cần chia sẻ dữ liệu xác thực với các dịch vụ khác. Ví dụ: trong kiến trúc microservice, JWT được tạo bởi dịch vụ xác thực có thể được xác minh và tin cậy bởi các dịch vụ khác mà không cần phải liên hệ với dịch vụ xác thực trên mỗi yêu cầu. Nếu bạn chọn JWT, hãy cân nhắc triển khai mã thông báo làm mới (refresh token) để cân bằng giữa bảo mật và trải nghiệm người dùng. Mã thông báo làm mới cho phép bạn sử dụng mã thông báo truy cập (access token) có thời gian tồn tại ngắn để hạn chế phạm vi lạm dụng tiềm ẩn, đồng thời cho phép người dùng duy trì trạng thái đăng nhập trong một khoảng thời gian dài. Tóm lại, sự lựa chọn phụ thuộc vào nhu cầu và kiến trúc cụ thể của ứng dụng của bạn.

6:44 Nếu bạn thích video này, có thể bạn cũng sẽ thích bản tin về thiết kế hệ thống của chúng tôi. Bản tin này bao gồm các chủ đề và xu hướng trong thiết kế hệ thống quy mô lớn, và được tin tưởng bởi 500.000 độc giả. Đăng ký tại blog(dot)bytebytego(dot)com.