Có cần thiết phải sử dụng refresh token (RT) hay không? Hay chỉ access token (AT) là đủ? Hãy cùng tìm lời giải đáp trong bài viết dưới đây nhé! 

Token là gì?

Cho những ai chưa biết, token là một đoạn string (thường là jwt, tuy nhiên hiện nay cũng có rất nhiều loại token khác nhau). Chúng được dùng để đại diện cho người dùng thao tác vào hệ thống. Ví dụ như khi bạn đăng nhập vào hệ thống sẽ trả về cho bạn một AT, bạn lưu lại mã AT đó cho mỗi lần gọi API sau đó.

Nếu như các trang web được xây dựng theo phong cách server render thì ngoài cách triển khai AT và RT chúng ta còn có thể định phiên người dùng bằng session – cookie. Nhưng xu thế ngày nay đang hướng đến những trang web client render như React, Angular, Vue… thì việc triển khai AT và RT rất là phổ biến.

Uỷ quyền là gì? Tại sao cần uỷ quyền?

Thông thường, việc xây dựng một website thì tính năng đăng ký/đăng nhập khá phổ biến. Một khi đăng nhập, bạn sẽ phải nhập một tài khoản và mật khẩu để xác nhận danh tính. Hệ thống xác nhận thông tin được nhập là chính xác thì sẽ trả về cho bạn một đoạn mã AT để đại diện cho bạn với một số quyền hạn nhất định trong hệ thống đó.

Trong Oauth, vấn đề ủy quyền sẽ xuất hiện khi ta bấm vào nút đăng ký/đăng nhập bằng tài khoản Google, Facebook… Khi đó, hệ thống sẽ chuyển bạn qua một màn hình mà ở đó bạn sẽ phải đồng ý với việc cho phép cho hệ thống kia lấy một số thông tin như email, tên, ngày tháng năm sinh… của bạn. Khi đó thì Google hay Facebook cũng trả về một mã AT mà dựa vào đó, hệ thống kia có thể lấy được những thông tin của bạn phục vụ cho mục đính xác nhận danh tính.

Tóm gọn, ủy quyền chính là việc xác nhận danh tính để lấy được một đoạn mã AT mà dựa vào mã AT đó có thể thay mặt người dùng để sử dụng được hệ thống.

Đôi khi, việc có mã AT gần như sẽ có luôn tài khoản của bạn trong một hệ thống nào đó. Nếu mã AT bị lộ thì sẽ rất nguy hiểm bởi nó sẽ tạo điều kiện cho các kẻ tốn công làm giả danh tính của bạn và thực hiện các việc xấu. Chính vì lý do đó mã AT cần được lưu trữ một cách nghiêm ngặt nhất có thể, hoặc nếu không hãy giảm thời gian hiệu lực của mã AT.

Ví dụ: Một mã AT chỉ có hiệu lực trong thời gian 5 phút, hết 5 phút sẽ yêu cầu người dùng đăng nhập lại.

Mối quan hệ của Access Token và JWT#

Thông thường, mã AT cũng chính là mã JWT (json web token). Nó là một tiêu chuẩn để truyền thông tin an toàn giữa các bên với dữ liệu là một đối tượng JSON. Thông tin này có tính tin cậy cao bởi bởi nó đã được kí bằng mã bảo mật bằng cách sử dụng các thuật toán như HMAC, RSA hoặc ECDSA.

Một đối tượng JWT gồm có 3 phần là header, payload và signature. Trong đó header giữ các thông tin cơ bản về chuỗi JWT như thuật toán dùng để kí, hạn sử dụng… Payload là dữ liệu cần truyền tải là đối tượng JSON đã được base64 encode. Cuối cùng là signature là phần mã hóa của cả hai header và payload kết hợp với mã bí mật cùng thuật toán mã hóa đã được chỉ định ở header.

Để tìm hiểu kĩ hơn về JWT, các bạn có thể đọc thêm ở Introduction to JSON Web Tokens. Vì những thông tin cần thiết để truyền tải được nằm trong payload thế nên dựa vào payload hệ thống có thể xác định được danh tính của người dùng thông qua nó.

Ví dụ một payload có nội dung như sau:

• {  
•   “id” : 1,  
•   “username”: “hoaitx”  
• }  

Như vậy, khi lên hệ thống sẽ đọc được id của đó và xác định được chủ sở hữu là ai.

Có một lưu ý cực kì quan trọng đó là thông tin trong payload chỉ được mã hóa bằng base64, điều đó có nghĩa từ mã JWT nhất định có thể trích xuất được những thông tin có trong payload. Vì vậy, bạn cần thận trọng trong việc đưa thông tin vào payload trước khi kí chúng. Hãy chắc chắn rằng những thông tin nhạy cảm như password, hay các thông tin cá nhân không cần thiết không được đưa vào.

 

Khi mã JWT được gửi lên máy chủ có thể dễ dàng xác định được phần chữ kí trong đó có hợp lệ không. Bởi bất kì một thông tin nào trong payload được sửa đổi để gửi lên sẽ kéo theo chữ kí sẽ bị thay đổi theo. Chưa kể đến kẻ tấn công sẽ không bao giờ biết được mã bí mật dùng để kí lại nội dung bị thay đổi đó.

Có nên dùng Refresh Token không?#

Sẽ không có câu trả lời cụ thể cho việc nên triển khai RT hay như thế nào. Hiện nay, có nhiều hệ thống không cần triển khai đến RT mà vẫn hoạt động tốt. Tuy nhiên, có một vài lý do để AT chỉ nên tồn tại trong thời gian ngắn như:

• Access Token là một đoạn mã ủy quyền đã được kí bởi máy chủ ủy quyền, máy chủ tài nguyên chỉ cần nhận access token và xác nhận thế nên thời gian càng ngắn thì nguy cơ access token khi bị lộ càng ít rủi ro.
• Nếu thời gian hợp lệ của AT quá dài, khi bị lộ AT thì rủi ro cao hơn vì t kẻ gian có nhiều thời gian hơn để khai thác, đồng thời có thể bạn không biết rằng AT đã bị lộ.

Hãy tưởng tượng nếu bạn cho phép người dùng tạo quá nhiều mã AT, nếu muốn vô hiệu hóa những mã AT còn lại thì bạn phải đánh dấu nó trong cơ sở dữ liệu. Hay nói cách khác là bạn cần phải lưu lại những mã AT đã được tạo ra.

Hãy cẩn thận phân biệt máy chủ ủy quyền và máy chủ tài nguyên. Máy chủ ủy quyền có nhiệm vụ cung cấp mã RT và kí mã AT để đại diện cho người dùng. Máy chủ tài nguyên nhận mã đã kí từ máy chủ ủy quyền để có quyền như người dùng đang thao tác với dữ liệu của họ trên hệ thống như thông tin tài khoản, dữ liệu,… Máy chủ ủy quyền và máy chủ tài nguyên hoàn toàn có thể là một. RT thường được lưu trữ ở máy chủ ủy quyền phục vụ cho mục đích cấp mã AT mới. Còn mã AT được dùng ở máy chủ tài nguyên, dùng để định danh một người dùng.

Không nhất thiết phải lưu lại nhiều AT, nếu muốn chấm dứt phiên, bạn hãy vô hiệu hóa mã RT trên máy chủ ủy quyền.

Hi vọng bài viết trên đã phần nào giải đáp được các thắc mắc của các bạn lập trình viên. Chúc các bạn học tập và làm việc hiệu quả!

Bộ môn Công nghệ Thông tin
Trường Cao đẳng FPT Mạng cá cược bóng đá cơ sở Hà Nội