Reset lại token mới khi token cũ hết hiệu lực

#1

Chào các bạn của tôi,
Tôi đã mở một API với xác thực JWT khi gọi nó cho trang wordpress của tôi và nó đang hoạt động.
Bây giờ tôi muốn đặt thời gian hết hiệu lực cho cái token đã gửi đến client.
Tôi có 2 solution :

tôi sẽ cho expired là 20 minutes
1/ Khi token mà tôi đã gửi, gần đến thời gian hết hiệu lực, server của tôi sẽ overwrite lại token của user (user sẽ không biết được điều gì đã xảy ra)
2/ Khi token đến thời hết hiệu lực, server của tôi không làm gì cả chỉ đơn giản là return 403 và user sẽ authentication lại như cách mà chúng đã làm để lấy được cái token trước đó vậy (sẽ làm cho anh ta nghĩ rằng session của anh ta đã bị timeout)

Các bạn hãy giúp tôi chọn 1 và tôi chấp nhận phương án thứ 3 !
Cảm ơn rất nhiều những người hàng xóm tốt bụng và đáng yêu.

#2

Cảm ơn cậu về câu hỏi nhé!
Tớ sẽ giải thích các vấn đề với các solution mà cậu đưa ra.

Khi cậu overwrite token của client trên server mà client không biết, cậu không thể xác thực các request tiếp theo từ client, khi client sử dụng old token.

Thực ra cậu nên return HTTP status 401 (unauthorized, và được đề cập tại rfc6750 spec). 403 có nghĩa là “forbidden”, hiểu là tài khoản cậu không được phép truy cập vào resource đó.
Cậu chỉ cần thay đổi điều đó ở solution thứ 2 của cậu. Đó là 1 solution tốt.

Ngoài ra, cậu có thể có 1 solution khác, đó là khi issue token, ngoài refresh token & access token, server còn đưa thêm thời điểm token bị expired (expires_in). Như vậy, client sẽ biết lúc nào token expire, và chủ động issue new token tại thời điểm gọi.

Cậu có thể chọn cách thực hiện phù hợp với design hiện tại của hệ thống.

See also:




15 Likes
#3

@library cảm ơn người bạn của tôi,
Tôi đã hoàn thành xong authentication cùng JWT với những thứ bạn đưa cho tôi bên trên nhưng bây giờ tôi lại muốn authorization trang web của tôi thành nhiều quyền hạn ! Tôi lại tiếp tục băn khoăn về 2 solution :
1/ gửi kèm role (administrator, accounting, member, …) vào payload của JWT token. Mỗi khi anh ta request đến tài nguyên được bảo vệ, server sẽ parse payload lấy role và điều hướng anh ta đến nơi thích hợp.
2/ tất cả payload token đều chỉ lưu username, khi mà anh ta request đến source anh muốn, server của tôi sẽ truy vấn role trong database dựa vào username của anh ta để lấy lên role.

Tôi lại làm phiền người anh em lần thứ 2 !

3 Likes
#4

Hi,
Không nên lưu list role vào token nhé, nên truy vấn database để lấy role mỗi khi authentication thành công.

2 Likes
#5

Mình nghĩ lưu quyền vào payload của token cũng không ảnh hưởng gì đến bảo mật hết. VD trong payload lưu quyền là user, người ta cố ý sửa thành admin thì token cũng đâu sử dụng được.

#6

Nhưng như vậy thì phải đợi token expired mới truất quyền thành công.

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

For example, you might run a file-hosting service where the user has to authenticate to download their files, but the files themselves are served by a separate, stateless “download server”. In this case, you might want to have your application server (Server A) issue single-use “download tokens”, that the client can then use to download the file from a download server (Server B).

9 Likes
#7

Tôi hiểu vấn đề của anh bạn, tôi chắc chắn rằng client tự ý thay đổi payload dẫn đến token không thể validate. Nhưng vấn đề chính ở đây như anh bạn bên trên đã nói, JWT filter layer không giữ liên lạc với database, chúng không sync, nó dường như không hề hay biết token mà nó vừa cho pass qua đã bị disable ở tận bên trong database rồi. Và thế là mặc dù tài khoản của anh ta đã bị disable như anh ta vẫn vô tư truy cập vào trang web admin của tôi.

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?