Câu hỏi về cách lưu Refresh Token, và quy trình của token và refresh token

câu trả lời ko mang tính bao hàm tất cả mọi trường hợp

Đoạn tìm hiểu của e về access token và refresh token là đúng đó e, đó cũng là những gì cơ bản nhất khi nói về access và refresh token

Về việc lưu refresh token trong DB

Như vậy em có 1 thắc mắc sau là khi token chết, thì làm cách nào để server kiểm tra tính hợp lệ của refresh token?

Sau khi access token expired thì e query lại lên server dùng refresh token, server nó sẽ check trong DB nếu cái refresh token của e match thì trả về access token mới cho e. (nhằm đảm bảo token đó đc generated bởi server, đc lưu lại trong DB của server)

Sau khi suy nghĩ thì em đưa ra câu hỏi tiếp là liệu refresh token vừa được client lưu ở local giống token và vừa được lưu trong DB?

Đó như bên trên a đã nói lúc server check refresh token của e trong DB nếu ko match với phía client của e gửi lên thì bắt login lại

Nếu như nó được lưu ở client rồi thì cần gì phải lưu ở DB trong khi server vẫn có thể kiểm tra tính hợp lệ và độ sống còn của nó giống thằng Token?

Câu này hay ). Một trong những mục đích người ta thường dùng khi lưu token (cả access token và refresh token) trong DB đó là để có thể revoke token bất kì lúc nào (huỷ bỏ token). Ví dụ như Facebook cho login trên nhiều thiết bị, mỗi thiết bị có 1 token, và mình muốn logout khỏi thiết bị nào thì revoke token của thiết bị đó. Lưu token trong DB thì cho phép ta quản lý được tokens (số lượng, ai sở hữu,...)

Và nếu như nó cũng được lưu như token thì chẳng phải token và refresh token nó gần như là 1 hay sao

Không phải . Access token là access token, refresh token là refresh token. E ko thể dùng Refresh token để truy cập protected resources được, và đó ko phải bản chất của refresh token.

Việc lưu token ở đâu là tuỳ thuộc vào use case của e và e chọn 1 cách hợp lý nhất cho project của mình.

Token để ở cookie muốn bảo mật thì set httpOnly=true (ko thể đc truy cập bằng javascript), set thêm secure=true (chỉ đc dùng nếu web load bằng https), set thêm sameSite nữa thì cũng thêm 1 lần bảo mật ở phía client. Đây cũng là cách a thấy mọi người dùng nhiều hơn cả

Lưu token ở trong DB sẽ cho ta thêm 1 số tính năng nữa như revoke token bất kì lúc nào mong muốn (trường hợp refresh token của e mà "sống" lâu quá thì đây cũng có thể là 1 giải pháp), hay để check chính xác là refresh token gửi bởi client match với DB phía server (để chắc chắn token đc generate bởi server và đc lưu vào DB cẩn thận). Nếu ko lưu token vào DB thì mỗi lần login mình sẽ "sign" và trả về access + refresh token về cho user, lần tới user request dùng các token đó thì mình vẫn check đc là nó có hợp lệ hay ko, nhưng mình ko thể biết được ngoài kia hiện tại có bao nhiêu token của user, loại nào bao nhiêu, account nào sở hữu nhiều tokens,.... Đương nhiên việc lưu token trong DB này sẽ thêm việc cho server của e (e phải quản lý cả tokens), mà token là thứ user tạo ra liên tục, 1 account có thể có hàng chục/trăm token, nên nếu ko có cơ chế để remove unused/expired token thì DB của e lại overload (yes, lại thêm việc) .