Xác thực jwt token khi thông tin trong Database thay đổi

#1

Chào các bác.

Trước tiên cho e xin lỗi nếu title khó hiểu do e cũng chưa biết đặt sao cho đọc là thấy vấn đề ngay.
E đang làm asp net core và gặp 1 vấn đề như sau, mong bác nào biết có thể giải đáp giúp e.

E có dùng xác thực người dùng bằng JWT token trong .net core. Khi login sẽ query tới DB để lấy thông tin từ đó build ra token

-> Vậy khi thông tin của user đó trong DB thay đổi (VD: User bị deative hoặc change role) làm sao để xác thực lại (Khi token chưa hết hạn)

Ai biết xin chỉ giáo
E cám ơn!

#2

Thế cái token sinh ra để làm gì, chỉ dùng để lấy mỗi uid thôi hả bạn. Nếu role change thì cấm truy cập vào mục không được phép. deactivate thì response lỗi + http error code thích hợp, việc còn lại là thằng làm UI lo mà bắt login lại

1 Like
#3

Hình như bác chưa hiểu ý e.
VD:

  • 1 thằng user ABC login vào, khi này có có role là admin
  • Sau khi login thì thằng này đã có token, store trên client rồi.
  • Sau đó 1 thằng khác change role của thằng user ABCvề role là user -> token cũ vẫn verify được vì token đâu có sai, nó vẫn được sign, và server vẫn verify cho nó.
    Ý e mong muốn là làm sao custom được AuthorizeAttribute trong asp net core để mỗi lần verify thì nó query lại vào DB để check???
#4

Mỗi lần request gửi lên server, trước khi truy cập tài nguyên thì luôn có một bước verify cái token.
Thì ở bước verify đó, bạn thực hiện luôn cả việc verifyUserRole nữa.
Để làm vậy thì bạn để luôn cái userRole vào trong token.

#5

Sorry bạn, mình đọc không kĩ câu hỏi của bạn.
Mình có lượn qua 1 vài trang về vấn đề này thì thấy không có nói về cách để bắt phải query lại role mỗi lần verify trong .net core mà nó hoàn toàn dựa vào 1 khái niệm gọi là claim (tương tự với trên DNH). Tuy nhiên nhìn kiến trúc thì mình thấy bạn có thể custom behavior dựa vào việc viết 1 middleware đứng trước thằng authentication middleware để reload lại role của người dùng, từ đó từ chối sớm hoặc cho pass qua trước khi thằng authentication mặc định làm việc

2 Likes
#6

Bạn lưu cái gì trong token? Chắc chắc ít ra phải có 1 cái user id phải không?
Vậy tiếp theo, bạn hãy định nghĩa: thế nào thì gọi là “xác thực lại”?

#7

Theo ý kiến của mình thì không nên dùng stateless architechture (JWT token) trong việc xác thực thành viên (mặc dù JWT token nói chung hay stateless arch cũng có nhiều điểm thú vị).

#8

Có 2 cách:

  1. Khi change role của User thì cancel token của user đó luôn => bắt user phải login lại
  2. Khi User gửi request lẹn server thì sẽ có bước verify role trong token, thay vì verify ở Claim thì mình query xuống database để get Roles lên. (cách này sẽ bảo mật hơn, nhưng mỗi lần request thì phải call Db để query lại, tuy nhiên câu select Roles cũng không quá perfomance nên có thể dùng cách này)
1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?