1. Đầu tiên phải hiểu tại sao phải sinh ra lắm token như vậy để làm gì. Rốt cuộc thì mọi thứ sinh ra cũng chỉ để "bảo mật hơn" hoặc là "giảm thiểu thiệt hại" trong trường hợp việc bảo mật không thành công. Và việc sinh ra nhiều loại token như vậy để đáp ứng các yêu cầu này.

2. Tiếp theo thì khi nào cần sử dụng 2 loại token. Rõ ràng là nếu như chúng ta trả cả 2 loại token này cho client khi họ login thành công thì có vẻ chẳng có ý nghĩa gì cả, hacker tấn công vào cookie và họ có thể lấy cả 2 token thì sẽ chẳng có gì là bảo mật hơn cả. Thậm chí nó còn làm phức tạp vấn đề khi cứ vài phút lại phải dùng refresh token để lấy access token 1 lần.

Như vậy thì những ứng dụng chỉ đơn thuần là phục vụ cho 1 dịch vụ ví dụ như 1 website bán hàng chẳng hạn thì một loại token là đủ rồi.

Tuy nhiên giả sử có thêm một dịch vụ chat cho website bán hàng này chẳng hạn, dịch vụ chat này sẽ chỉ được lấy username và display name của user để hiển thị lên giao diện chat thôi chẳng hạn, thì lúc này sử dụng 2 loại token là phù hợp.

Ví dụ chúng ta có 2 dịch vụ chạy trên 2 domain thế này:

1. banhang.com: dịch vụ to nhất
2. chat.banhang.com: chỉ có chat.

Đầu tiên, khi mở giao diện chat thì client sẽ chuyển tiếp ngay đến banhang.com, thì banhang.com sẽ sinh ra 1 access token chỉ có hiệu lực trong x phút và sau đó trả lại cho chat.banhang.com qua redirect. Lúc này thì cho dù access token bị lộ nhưng hacker cũng chẳng làm gì được.

Nói tóm lại việc sinh ra nhiều loại như vậy để phục vụ tốt hơn cho việc phân quyền để bảo mật hơn và giảm thiểu thiệt hại khi bị tấn công.