thắc mắc Không cảm thấy refresh token thực sự giải quyết vấn đề

tonghoangvu · 24/7/24

xuanduy1508 đã nói:
Em cảm ơn hai bác vì câu trả lời chi tiết ạ. Nhưng em vẫn cảm thấy rằng một JWT access token thôi cũng đủ sức làm chuyện này rồi ạ.

VD một scenarios như này

Legit User (LU) sau khi login có 1 access token (AT1)

Malicious User (MU) đánh cắp được AT1 từ LU

LU gửi request gì đó như post một Product mới lên server cùng với AT1
Nếu AT1 valid, cho LU post một Product mới và cung cấp cho LU một AT mới là AT2

MU sau đó cũng sử dụng AT1 (đã bị đánh cắp từ trước) để gửi refresh lên server → AT reuse detected

Xong rồi revoke AT2 bắt LU login lại và cảnh báo LU

Đó, theo em thấy thì một mình một token thôi cũng đủ để xử lý vấn đề rồi ạ. Cơ sự gì xin ra 2 thằng riêng biệt AT với RT chi ạ

Ừm bạn có tính đến trường hợp login nhiều device cùng lúc chưa nhỉ?

devquenok · 24/7/24

khanhdayne đã nói:
cho em hỏi bên frontend sẽ xử lý việc tự động gửi request này
như nào ạ

Keyword Interceptor, vidu axios interceptor. Bạn tự search nha.

xuanduy1508 · 24/7/24

tonghoangvu đã nói:
Ừm bạn có tính đến trường hợp login nhiều device cùng lúc chưa nhỉ?

xài bình thường mà bạn, lúc đầu mình nghe giải thích của mấy ông kia thì cũng nghĩ nhiều device thì nó không hoạt động được nhưng mà nghĩ kỹ thì xài bth

xuanduy1508 · 24/7/24

AppSevi đã nói:
Chú cũng nhìn thấy đấy thì còn hỏi gì nữa nhỉ?

Cái cơ chế của chú là mỗi lần có request đều phải trả về AT mới, và lưu cái thông tin về AT mới nhất trên DB để verify được những requests từ AT không phải mới nhất. Như thế này sẽ phải lưu và write quá nhiều vào DB. Trong khi nếu dùng RT thì chỉ lâu lâu tạo AT mới thì mới phải lưu thông tin về cái AT mới này thôi. Mỗi request đến server vẫn phải read vào DB để check trước khi cho qua nhưng không phải write nhiều như cách của chú

à em hiểu r, nhìn chung là giảm workload cho database thôi đúng k. Em cảm ơn ạ

Love U So Much · 25/7/24

xuanduy1508 đã nói:
à em hiểu r, nhìn chung là giảm workload cho database thôi đúng k. Em cảm ơn ạ

Tất cả là vì performance my fen. Fen để ý 1 case khác là SSL trust trên browser, đoạn đầu là cũng dùng cert trusted, giảm tải :LOL:

xuanduy1508 · 29/7/24

Cảm ơn các anh em đã rep câu hỏi của em nha, có mấy người em không biết rep sao hết vì em chả biết rep gì. Nói chung là em cảm ơn vì đã hỗ trợ em nha :love:

xuanduy1508 · 29/7/24

-Stark- đã nói:
Tăng thời hạn của AT thì attacker khi chiếm đc AT sẽ có nhiều thời gian access vào resouces server hơn
Solution → giảm valid time của AT (eg. 1 hour) → khi AT expired, client app sẽ tự động gửi request đến Authorization Server để get new pair of AT và RT (cả RT cũng sẽ được cấp mới)

Attacker hoàn toàn có thể chiếm đc RT.
Các Authorization Server thường implement một cơ chế gọi là Automatic Reuse Detection để detect việc RT được reuse.
VD một scenarios như này

Legit User (LU) có RT1 và AT1

Malicious User (MU) đánh cắp được RT1 từ LU

LU sử dụng RT1 để get 1 cặp RT và AT mới

Authorization Server trả về RT2 và AT2 cho LU

MU sau đó cũng sử dụng RT1 (đã bị đánh cắp từ trước) để get một cặp AT và RT mới → RT reuse detected

Để implement được cơ chế này thì các Authorization Server thường lưu các token family, nghĩa là từ một RT ban đầu sẽ có link tới các RT đã được generate sau đó, có thể dùng linked list.
Khi MU cố gắng sử dụng RT1 (đã bị đánh cắp từ trước) để get một cặp AT và RT mới → Authorization Server sẽ check được RT1 được sử dụng trước đó → invalidates toàn bộ tokens trong token family hiện tại → RT2 và AT2 mà LU đang sử dụng cũng sẽ bị invalidated → LU sẽ phải thực hiện đăng nhập lại

AT chỉ là token để access vào Resources Server, còn RT sẽ tăng thêm bảo mật cho hệ thống (bằng các chế được mô tả ở trên). VD nếu dùng RT với service của Auth0 thì mình sẽ không phải tự implement cơ chế Automatic Reuse Detection vào Resource Server.
Xem tệp đính kèm 2591820

Em search thì chả thấy ai dùng linked-list hết. Em implement thì oke nhưng mà sợ không phải best practice. Bác có thể gửi tài liệu cho em tham khảo được không. Với dùng DSU có phải ý kiến hay không bác

anhnmt · 29/7/24

Refresh token mình đang triển khai thì có kết hợp thêm vài thông tin để theo dõi xem có bị leak không bằng cách nếu user dùng RT trên 1 thiết bị mới hoặc dùng RT 2 lần trở lên thì cho vào diện cảnh báo bị leak.

canh_1412 · 29/7/24

Refresh tokens are credentials used to obtain access tokens when the current access to becomes invalid or expires
Định nghĩa có vậy thôi, thêm mắm thêm muối làm gi.
Có 2 use case thế này:
Làm chức năng login dùng JWT. Nếu người dùng tích vào nút remember me thì lần sau không cân login nữa mà tự động vào? thím làm thế nào :rolleyes:

Rồi trong trường hợp buồn buồn thím thay secrect key gen JWT. giờ không muốn bắt user login lại thì làm sao?

-Stark- · 30/7/24

xuanduy1508 đã nói:
Em search thì chả thấy ai dùng linked-list hết. Em implement thì oke nhưng mà sợ không phải best practice. Bác có thể gửi tài liệu cho em tham khảo được không. Với dùng DSU có phải ý kiến hay không bác

Cái này là do mình suy đoán dựa trên kiến trúc của Auth0.
Mình thường mình cũng sẽ dùng các service hoặc lib có sẵn chứ cũng chưa tự implement.
Fen có thể tham khảo thêm ở đây

What Are Refresh Tokens and How to Use Them Securely

Learn about refresh tokens and how they help developers balance security and usability in their applications.

auth0.com

daicatoanmasao · 31/7/24

hóng

qkhanhpro · 31/7/24

Một lợi ích khác nữa là cơ chế blacklist. Giả sử 1 token của khách hàng đã bị báo lộ, nếu bạn đặt cơ chế blacklist ở AT level thì mỗi lần access của mỗi khách hàng sẽ, phải lookup rất lãng phí và không thể cache được, chưa nói đến việc AT được thiết kế để mang đến resource srv, không phải idsrv

Còn RT được thiết kế để mang đến idsrv đổi lấy AT. Thiết kế black list RT tập trung ở idsrv mà không bị hao phí tài nguyên, roundtrip ...

phuctienn · 5/9/24

xuanduy1508 đã nói:
xài bình thường mà bạn, lúc đầu mình nghe giải thích của mấy ông kia thì cũng nghĩ nhiều device thì nó không hoạt động được nhưng mà nghĩ kỹ thì xài bth

Nhiều device hoạt động sao vậy bác.

Ví dụ khi đăng nhập device 1 sẽ có RT1, AT1
Đăng nhập device 2 thì tạo ra cặp RT2, AT2, nếu vậy thì cặp RT1, AT1 ở device1 không dùng được nữa vì RT1 không khớp với RT mới nhất => mỗi lần vào 1 thiết bị người dùng phải đăng nhập 1 lần

Nếu lưu nhiều refreshtoken cho mỗi device thì em thấy nó không còn ý nghĩa bảo mật nữa

xuanduy1508 · 6/9/24

phuctienn đã nói:
Nhiều device hoạt động sao vậy bác.

Ví dụ khi đăng nhập device 1 sẽ có RT1, AT1
Đăng nhập device 2 thì tạo ra cặp RT2, AT2, nếu vậy thì cặp RT1, AT1 ở device1 không dùng được nữa vì RT1 không khớp với RT mới nhất => mỗi lần vào 1 thiết bị người dùng phải đăng nhập 1 lần

Nếu lưu nhiều refreshtoken cho mỗi device thì em thấy nó không còn ý nghĩa bảo mật nữa

mỗi device là mỗi cặp RT AT riêng biệt không có họ hàng gì với nhau @@ cặp RT AT ở điện thoại chả liên quan gì tới cặp RT AT trên máy tính cả

phuctienn · 8/9/24

xuanduy1508 đã nói:
mỗi device là mỗi cặp RT AT riêng biệt không có họ hàng gì với nhau @@ cặp RT AT ở điện thoại chả liên quan gì tới cặp RT AT trên máy tính cả

Nếu thế thì mỗi thiết bị phải lưu 1 trường RT hay sao ạ, kiểu mobileRT, tabletRT, ... có cách nào để không giới hạn thiết bị không ạ

thanhx0kjt · 8/9/24

xuanduy1508 đã nói:
[*]LU gửi request gì đó như post một Product mới lên server cùng với AT1
Nếu AT1 valid, cho LU post một Product mới và cung cấp cho LU một AT mới là AT2

Cái này theo Oauth2 là không chính xác. Bạn cần phân biệt thằng Resource Server (là service cung cấp Product API ) và thằng Authentication Server ( cung cấp AT và RT) là 2 thằng khác nhau. Gần nhưng không liên quan/ giao tiếp gì với nhau ngoại trừ lúc đồng ý cơ chế cho JWT token

via theNEXTvoz for iPhone

gintaku123123 · 8/9/24

thanhx0kjt đã nói:
Cái này theo Oauth2 là không chính xác. Bạn cần phân biệt thằng Resource Server (là service cung cấp Product API ) và thằng Authentication Server ( cung cấp AT và RT) là 2 thằng khác nhau. Gần nhưng không liên quan/ giao tiếp gì với nhau ngoại trừ lúc đồng ý cơ chế cho JWT token

via theNEXTvoz for iPhone

Mình có thắc mắc là trường hợp user revoke Access Token (với Authentication Server) thì làm sao Resource Server nó biết được là cái Access Token bị revoke đó invalid nhỉ?

Edit: Hỏi thg chatGPT thì có vẻ là phải thêm cơ chế giao tiếp giữa 2 thg Resource Server và authorization server để thg AS báo thg RS khi có event revoke xảy ra chứ còn ko thì thg RS sẽ ko care việc revoke đó cho đến khi Access Token đó tự expire. (mà hình như chỉ có revoke Refresh token chứ Access Token Expiration nó ngắn nên chắc ko có revoke đc nhỉ :v)

thanhx0kjt · 8/9/24

-Stark- đã nói:
Khi MU cố gắng sử dụng RT1 (đã bị đánh cắp từ trước) để get một cặp AT và RT mới → Authorization Server sẽ check được RT1 được sử dụng trước đó → invalidates toàn bộ tokens trong token family hiện tại → RT2 và AT2 mà LU đang sử dụng cũng sẽ bị invalidated → LU sẽ phải thực hiện đăng nhập lại

Đoạn này mình nghĩ cũng không chính xác, có thể AS sẽ validate và không cung cấp AT nữa. Nhưng việc invalidate các AT trước đó không có tác dụng. Bản chất việc validate AT, RS có thể tự check được mà không cần giao tiếp với AS
Ví dụ: JWT dùng private key để sign ra AT thì RS chỉ cần dùng public key tương ứng là có thể validate được

via theNEXTvoz for iPhone

thanhx0kjt · 8/9/24

gintaku123123 đã nói:
Mình có thắc mắc là trường hợp user revoke Access Token (với Authentication Server) thì làm sao Resource Server nó biết được là cái Access Token bị revoke đó invalid nhỉ?

dev quèn 234 đã nói:
Nếu dùng JWT thì self-contained nên cần gì gửi tới resource server bác nhỉ.
Theo mình thì access token short-live sẽ được resource server check 1 cách độc lập, không đi kèm các cơ chế detect nặng như các bác nêu ở trên. Và khi bị leak thì attacker có rất ít thời gian để tấn công
Ngược lại mục đích của refresh token long-live là chỉ gửi khi renew access token nên khó bị leak. Mình đọc flow thấy khi renew thì phải gửi kèm cả client-id và client-secret tới authorization server nên dù bị leak vẫn không sao nhỉ. Mong các bác giải đáp

Như comment của bác này, Oauth2 không dùng các cơ chế nâng cao như vậy để validate AT. Thay vào đó thời gian sống của AT thường rất ngắn
Nên theo mình trường hợp revoke AT token không make sense cho lắm.

via theNEXTvoz for iPhone

gintaku123123 · 8/9/24

thanhx0kjt đã nói:
Như comment của bác này, Oauth2 không dùng các cơ chế nâng cao như vậy để validate AT. Thay vào đó thời gian sống của AT thường rất ngắn
Nên theo mình trường hợp revoke AT token không make sense cho lắm.

via theNEXTvoz for iPhone

tks bác, mình cũng mới research xong có update ở comment gốc

thắc mắc Không cảm thấy refresh token thực sự giải quyết vấn đề

Member

Senior Member

Junior Member

Junior Member

Senior Member

Junior Member

Junior Member

Senior Member

Senior Member

Member

Senior Member

Đã tốn tiền

Senior Member

Junior Member

Senior Member

Đã tốn tiền

Senior Member

Đã tốn tiền

Đã tốn tiền

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này