thắc mắc Tại sao mọi người hay dùng JWT cho authentication?

GeniVN

GeniVN

Senior Member
Chào các bác ạ,

Em đang đọc cuốn Modern API Development with Spring Boot và họ hướng dẫn việc dùng JWT để xử lý authentication. Mặc dù em có hiểu sử dụng nó như thế nào nhưng khi đọc thêm trên Stack Overflow và article này, thì em lại chưa hiểu tại sao phải sử dụng JWT thay cho sessions, hay đúng hơn là tại sao mọi người lại sử dụng chúng thay sessions ạ?

Có 1 thời gian thực tập thì em cũng có dùng API và thấy chúng toàn dùng JWT cho authentication ạ.

Mong các bác giải thích cho em hiểu ạ :(
 
Following https://auth0.com/docs/secure/tokens/json-web-tokens
JWTs are a good way of securely transmitting information between parties because they can be signed.
More info: http://jwt.io
Túm lại thì jwt dùng format phổ biến (json), bảo mật, encode ngắn hơn SAML (dùng XML mấy API cũ lúc test bằng curl mệt này). Nó có thể dùng để Authentication, Authorization thậm chí là Information Exchange.
Anw, thật ra sessions và JWTs cũng có một số điểm tương đồng nhưng khái niệm nó khác nhau lắm.
 
Last edited:
GeniVN said:
Chào các bác ạ,

Em đang đọc cuốn Modern API Development with Spring Boot và họ hướng dẫn việc dùng JWT để xử lý authentication. Mặc dù em có hiểu sử dụng nó như thế nào nhưng khi đọc thêm trên Stack Overflow và article này, thì em lại chưa hiểu tại sao phải sử dụng JWT thay cho sessions, hay đúng hơn là tại sao mọi người lại sử dụng chúng thay sessions ạ?

Có 1 thời gian thực tập thì em cũng có dùng API và thấy chúng toàn dùng JWT cho authentication ạ.

Mong các bác giải thích cho em hiểu ạ :(
Click to expand...
JWT và sessions sao lại thay cho nhau là sao nhỉ, 2 khái niệm hoàn toàn khác nhau, à đọc phần

A note upfront​

thì chắc fen nói đúng rùi
nhưng vẫn thấy khó hiểu:go:
 
Đơn giản là jwt không cần phải lưu trữ lại. Nhờ đó:
  • xử lý nhanh hơn vì không cần access vào db để check
  • tiết kiệm bộ nhớ
  • quan trọng nhất, là có thể đc issue bởi một bên cung cấp và verify bởi một bên thứ 3 khác, mà không cần share gì thêm. Nhờ đó dễ dàng implement đc các oauth flow.
 
Vipluckystar said:
Following https://auth0.com/docs/secure/tokens/json-web-tokens
JWTs are a good way of securely transmitting information between parties because they can be signed.
More info: http://jwt.io
Túm lại thì jwt dùng format phổ biến (json), bảo mật, encode ngắn hơn SAML (dùng XML mấy API cũ lúc test bằng curl mệt này). Nó có thể dùng để Authentication, Authorization thậm chí là Information Exchange.
Anw, thật ra sessions và JWTs cũng có một số điểm tương đồng nhưng khái niệm nó khác nhau lắm.
Click to expand...
session là stateful, JWTs là stateless mà tương đồng gì ?
JWTs mà ko có SSL thì cũng đâu có nghĩa là bảo mật, nó chỉ là 1 phương pháp lưu trữ state của client lên thôi.
 
Lập Trình Viên Số Khổ said:
thật luôn á, trước giờ tui tưởng chỉ có secret key

vãi ô đùa tui à

ô có cái flow ý k cho tui với xem với
Click to expand...

À có nhiều cách để sign cái jwt. Cái tui nói là dùng rsa. Ông có thể dùng khoá đối xứng cũng đc nhưng như thím trên nói nó k bảo mật.

Ngủ rồi mai share link sau nha fen.

via theNEXTvoz for iPhone
 
Hồi mới tìm hiểu jwt, cũng thấy nó màu hồng lắm, kiểu tự self verify thì không cần phải IO check chỗ khác nữa. Nhưng sau gặp nhiều case mới thấy không như là mơ.
Vì self verify thì chỉ có check signature với kiểm tra expire time. Vậy làm thế nào để invalid 1 token?
Ví dụ như mobile dùng jwt để authen vào server, vậy giờ server làm sao để force logout token đó đi? Giải pháp chấp vá là giảm expire time xuống, khi đó thì sẽ luôn có 1 khoảng delay time, mà như vậy với case end user thì quá fail. Giải pháp thứ 2 là vẫn phải lưu cái token đó vào chỗ nào đó để check :LOL:. Chỉ có điều là thay vì thằng app business phải tự code việc lưu token vào db rồi code đoạn check, thì giờ nó đẩy việc này cho mấy thằng gateway hoặc thằng authen server (không phải việc của coder ae mình). Lúc này nó ra đời khái niệm là "introspection token", nôm na là vẫn phải IO ra đâu đó để check.

Cái lợi ích khác của jwt ít người nói, đó là "claim value", tức là thông tin user có trong token luôn, claim token ra để lấy :3, nhưng cái dở của jwt đó là phần payload nó là encode (nhắc lại là encode chứ ko phải encrypt). Bọn nó mang 1 tư tưởng là "tao cho mày xem thông tin của tao đó, nhưng mày có xem được, cũng chả fake được đâu". Chính cái tư tưởng này mà có thằng PASETO ra đời, đáng tiếc cho PASETO là hồi mình nghiên cứu nó thì nó còn khá mới, chưa phổ biến.
 
GeniVN said:
Cho em hỏi câu nữa (chắc đúng hơn) là khi nào nên dùng session và khi nào nên dùng JWT authentication ạ?
Click to expand...
Ngoài ra session định nghĩa nó lưu theo phiên thế thì token lợi hơn khi bạn chạy trên nhiều server, qua loadbalance
 
karenshii said:
Hồi mới tìm hiểu jwt, cũng thấy nó màu hồng lắm, kiểu tự self verify thì không cần phải IO check chỗ khác nữa. Nhưng sau gặp nhiều case mới thấy không như là mơ.
Vì self verify thì chỉ có check signature với kiểm tra expire time. Vậy làm thế nào để invalid 1 token?
Ví dụ như mobile dùng jwt để authen vào server, vậy giờ server làm sao để force logout token đó đi? Giải pháp chấp vá là giảm expire time xuống, khi đó thì sẽ luôn có 1 khoảng delay time, mà như vậy với case end user thì quá fail. Giải pháp thứ 2 là vẫn phải lưu cái token đó vào chỗ nào đó để check :LOL:. Chỉ có điều là thay vì thằng app business phải tự code việc lưu token vào db rồi code đoạn check, thì giờ nó đẩy việc này cho mấy thằng gateway hoặc thằng authen server (không phải việc của coder ae mình). Lúc này nó ra đời khái niệm là "introspection token", nôm na là vẫn phải IO ra đâu đó để check.

Cái lợi ích khác của jwt ít người nói, đó là "claim value", tức là thông tin user có trong token luôn, claim token ra để lấy :3, nhưng cái dở của jwt đó là phần payload nó là encode (nhắc lại là encode chứ ko phải encrypt). Bọn nó mang 1 tư tưởng là "tao cho mày xem thông tin của tao đó, nhưng mày có xem được, cũng chả fake được đâu". Chính cái tư tưởng này mà có thằng PASETO ra đời, đáng tiếc cho PASETO là hồi mình nghiên cứu nó thì nó còn khá mới, chưa phổ biến.
Click to expand...
em có đọc được là thậm chí jwt nếu muốn invalidate 1 access key thì còn phải bổ sung thêm 1 cái blacklist, nghe chừng rất phức tạp nên cũng chưa rõ tại sao JWT lại dần được chuộng và khi nào nên dùng session-based authentication bác ạ :(

nhét public key vào client để lấy cái claim thì khác gì mua khoá rồi đưa chìa cho trộm đâu

em có hiểu thì JWT tiện để horizontal scale, triển khai trên mobile và ít logic hơn ở client hơn, chỉ biết mỗi vậy thôi ạ
 
Lập Trình Viên Số Khổ said:
thật luôn á, trước giờ tui tưởng chỉ có secret key

vãi ô đùa tui à

ô có cái flow ý k cho tui với xem với
Click to expand...
secret key áp dụng được trong trường hợp ông tự issue, tự validate thôi. Chứ ông builder Identity Provider cung cấp cho 1 bên thứ 3 mà ông đưa secret key cho nó verify thì sao đc. Như google nó cung cấp tới mấy public key để rotate đó. Standard thì nó sẽ có 1 trang docs discovery như này https://accounts.google.com/.well-known/openid-configuration trong đó có link dẫn tới certs, mấy thư viện để validate JWT nó cũng áp dụng chuẩn này hết
GeniVN said:
Cho em hỏi câu nữa (chắc đúng hơn) là khi nào nên dùng session và khi nào nên dùng JWT authentication ạ?
Click to expand...
Ngắn gọn thì có thể dùng JWT cho HTTP API, ứng dụng truyền thống như MVC, hoặc mấy dạng như reverse proxy thì có thể dùng cookie/ session

Session thì phía server của ông phải lưu lại 1 chỗ nào đó (memory? db?), JWT thì có thể "self-validate" đc, bao gồm cả những thông tin cơ bản như name, id của user cũng thường có sẵn trong token, ko cần phải lưu cái token hoặc query thêm user info lên làm gì. 1 cái nữa là JWT thì là stateless, Cookie/ session nó là stateful, chi tiết hơn thì search google tìm mấy bài đọc, nhiều mà.
 
hardcoreholly said:
secret key áp dụng được trong trường hợp ông tự issue, tự validate thôi. Chứ ông builder Identity Provider cung cấp cho 1 bên thứ 3 mà ông đưa secret key cho nó verify thì sao đc. Như google nó cung cấp tới mấy public key để rotate đó. Standard thì nó sẽ có 1 trang docs discovery như này https://accounts.google.com/.well-known/openid-configuration trong đó có link dẫn tới certs, mấy thư viện để validate JWT nó cũng áp dụng chuẩn này hết

Ngắn gọn thì có thể dùng JWT cho HTTP API, ứng dụng truyền thống như MVC, hoặc mấy dạng như reverse proxy thì có thể dùng cookie/ session

Session thì phía server của ông phải lưu lại 1 chỗ nào đó (memory? db?), JWT thì có thể "self-validate" đc, bao gồm cả những thông tin cơ bản như name, id của user cũng thường có sẵn trong token, ko cần phải lưu cái token hoặc query thêm user info lên làm gì. 1 cái nữa là JWT thì là stateless, Cookie/ session nó là stateful, chi tiết hơn thì search google tìm mấy bài đọc, nhiều mà.
Click to expand...
vâng cảm ơn bác ạ, em hiểu rồi :)
 
Dần dà thì mình thấy session hay jwt nó cũng na ná nhau cả, quanh đi quẩn lại đám authen thì cũng chỉ có mấy cái cơ chế đó, 1 là 2 bên tham gia, 2 là 3 bên tham gia.
Nói session thì phải rõ ý session đang đặt trong context nào để dễ bóc tách vấn đề.
Ví như local session trên mỗi server, thì sẽ phát sinh bài toán khi có nhiều server, thì session A được cấp bởi server A nhưng lại request tới server B.
Lúc đó thì lại giải pháp là dùng 1 con load balancer bên trên, lúc này lại ra đời trò sticky session để biết session được cấp bởi thằng nào thì sẽ redirect tới thằng đó.
Rồi thấy dườm dà quá, lại sinh ra thằng "shared session", kiểu như lưu session ở 1 cái db chung nào đó như redis chẳng hạn.
Rồi lại thấy cũng chưa thon gọn, lại đẩy việc authen cho thằng gateway làm luôn, đám service thì khỏi cần check lại.
 
GeniVN said:
em có đọc được là thậm chí jwt nếu muốn invalidate 1 access key thì còn phải bổ sung thêm 1 cái blacklist, nghe chừng rất phc tạp nên cũng chưa rõ tại sao JWT lại dần được chuộng và khi nào nên dùng session-based authentication bác ạ :(

nhét public key vào client để lấy cái claim thì khác gì mua khoá rồi đưa chìa cho trộm đâu

em có hiểu thì JWT tiện để horizontal scale, triển khai trên mobile và ít logic hơn ở client hơn, chỉ biết mỗi vậy thôi ạ
Click to expand...
uh đúng rồi JWT thì ko invalidate đc, chỉ có cái là lưu blacklist lại thôi, nên thường khi issue 1 cái JWT thì expiry nó rất ngắn, kèm theo là phải issue ra refresh token.

karenshii said:
Hồi mới tìm hiểu jwt, cũng thấy nó màu hồng lắm, kiểu tự self verify thì không cần phải IO check chỗ khác nữa. Nhưng sau gặp nhiều case mới thấy không như là mơ.
Vì self verify thì chỉ có check signature với kiểm tra expire time. Vậy làm thế nào để invalid 1 token?
Ví dụ như mobile dùng jwt để authen vào server, vậy giờ server làm sao để force logout token đó đi? Giải pháp chấp vá là giảm expire time xuống, khi đó thì sẽ luôn có 1 khoảng delay time, mà như vậy với case end user thì quá fail. Giải pháp thứ 2 là vẫn phải lưu cái token đó vào chỗ nào đó để check :LOL:. Chỉ có điều là thay vì thằng app business phải tự code việc lưu token vào db rồi code đoạn check, thì giờ nó đẩy việc này cho mấy thằng gateway hoặc thằng authen server (không phải việc của coder ae mình). Lúc này nó ra đời khái niệm là "introspection token", nôm na là vẫn phải IO ra đâu đó để check.

Cái lợi ích khác của jwt ít người nói, đó là "claim value", tức là thông tin user có trong token luôn, claim token ra để lấy :3, nhưng cái dở của jwt đó là phần payload nó là encode (nhắc lại là encode chứ ko phải encrypt). Bọn nó mang 1 tư tưởng là "tao cho mày xem thông tin của tao đó, nhưng mày có xem được, cũng chả fake được đâu". Chính cái tư tưởng này mà có thằng PASETO ra đời, đáng tiếc cho PASETO là hồi mình nghiên cứu nó thì nó còn khá mới, chưa phổ biến.
Click to expand...
JWT mà có cả mấy thông tin nhạy cảm thì là anti patterrn rồi. Muốn có những thông tin như thế thì implement caching phía backend thôi

Còn 1 lý do mà JWT phổ biến nữa là nó liên quan tới OAuth2, SSO. User login vô 1 Identity Provider rồi từ đó sử dụng các app khác mà ko phải login lại nó tiện hơn nhiều chứ

À còn ý nữa là việc user cấp quyền cho ứng dụng thông qua identity provider (kiểu tôi login vô voz = facebook nhưng ko muốn cho voz biết email chẳng hạn), thì dùng session/ cookie based sao làm (gọn) được
 

Similar threads

goodnga
thảo luận Có ai đang dùng Spring boot để phát triển ứng dụng java không ạ, cho e hỏi tý
2
Replies
34
Views
2K
Doan Minh Trung
Doan Minh Trung
D
thảo luận Xin kinh nghiệm triển khai mô hình Spark as a service cho enduser cho cụm Kurbenetes on premise
Replies
9
Views
593
DareDevil.a.k.MattMurdock
DareDevil.a.k.MattMurdock
trisongng
thắc mắc Nhờ mọi người tư vấn áo sơ mi
Replies
1
Views
150
phuclong_hl
phuclong_hl
NewOcer
thảo luận Chọn TCL Miniled hay Sony Full Array LED
Replies
3
Views
281
Ellen Ripley
Ellen Ripley
D
thắc mắc Thắc mắc về xung đột giữa Dock Dell 6000 và Macbook
Replies
2
Views
98
DaronD
D

Share this page

Back
Top