cứ học chắc network trước e nhé

@phhuy38 Hoàn toàn có thể dùng song song cả 2 ông nhé, không bắt buộc phải chọn 1. Tuy nhiên, sẽ ít ai cắm thẳng cả Session và JWT chung vào một cụm API hay service vì chi phí bảo trì khá mệt: code phải rẽ nhánh check 2 luồng auth liên tục, ví dụ một tính năng như "Logout khỏi tất cả các thiết bị" sẽ cực kỳ cồng kềnh vì phải đi dọn rác ở cả 2 nơi, vừa phải chọc DB xóa session cho Web, lại vừa phải đi xử lý revoke JWT cho mobile. Thực tế các hệ thống lớn vẫn xài cả 2 nhưng họ chia lớp rõ ràng: Web dùng Session gọi đến cổng Gateway cho an toàn, rồi Gateway mới đúc ra JWT đẩy xuống vùng lõi Microservices bên trong. Còn nếu làm chung một API phơi ra ngoài cho cả web lẫn mobile gọi trực tiếp, anh em thường quy về 1 chuẩn JWT từ đầu để đồng nhất và dễ maintain thôi.

78win là nền tảng giải trí trực tuyến được nhiều người tin tưởng nhờ hình ảnh chuyên nghiệp và định hướng phát triển bền vững. Sở hữu giao diện hiện đại, tối ưu trên mọi thiết bị, 78WIN mang đến trải nghiệm mượt mà, tiện lợi cùng dịch vụ hỗ trợ tận tâm, tạo dựng uy tín và dấu ấn riêng trên thị trường.

@ngocbach99 mình muốn hỏi là tại sao không thể dùng Session cho web và JWT cho Mobile cùng lúc mà bắt buộc phải dùng JWT cho cả 2.

bước 4 low threshold là ngương gì vậy ạ

Bài chi tiết quá ạ. Cảm ơn anh

đơn giản và đầy đủ

Ông vừa chạm đúng chỗ ngứa đấy =))). Nếu kiến trúc chỉ phục vụ Web thuần túy, Session + Cookie là vua. Nhưng khi có thêm Mobile App (Client không có trình duyệt chuẩn), việc ép mobile xài cookie đúng là cực hình. Lúc này, dùng JWT để đồng nhất giao tiếp cho cả Web và Mobile lại là sự đánh đổi hoàn toàn xứng đáng. Use-case của ông chính là một ngoại lệ hoàn hảo để chứng minh cho việc kiến trúc không có đúng sai tuyệt đối, chỉ có phù hợp với hoàn cảnh và bối cảnh nào thôi =)))😁

Bài viết khá hay và chi tiết. Nhưng mình có một thắc mắc nếu 'Monolith thì nên ưu tiên Session'. Trong trường hợp backend Monolith của mình phải phục vụ cả Web (React) và Mobile App (iOS/Android) thì sao? Quản lý cookie trên mobile khá phiền phức và khó chịu, lúc này dùng JWT chẳng phải tiện hơn Session nhiều sao??

Ông nhắc đến Keycloak là quá chuẩn rồi. Tool với framework bây giờ làm quá tốt, config vài dòng là xong, abstract kỹ quá nên nhiều anh em cứ cắm vào là chạy mà không rành luồng. Nhưng tới lúc trace bug mà không hiểu bản chất thì rớt nước mắt ngay. Rất vui vì bài viết có sự đồng điệu với ông 🤜🤛

Chính xác là không có gì tuyệt đối cả. Ý tưởng dùng jwks sinh ra cặp khóa cho từng microservice thực ra đã được áp dụng ở thằng keycloak. Có điều giờ nhiều ae dev chỉ dùng mà ko hiểu bản chất của nó. Cảm ơn chủ tus về 1 bài viết hữu ích

Cảm ơn b, mình đã sửa lại.

thú vị

1100$ b ơi

hướng đi hay nhé bạn

Sao video mình nén từ 1.8M xuất thành 3.5M vâyh

Một bình luận rất chuẩn xáccc🤩🤩. Trong khoa học máy tính, việc triệt tiêu hoàn toàn state là bất khả thi, và stateless tuyệt đối chỉ tồn tại trên lý thuyết. Còn bài toán thực sự đặt ra ở đây là mình quản trị nó ở đâu. Sự kết hợp giữa Opaque Token ở biên (API Gateway) và JWT ở vùng lõi (microservices) thực chất là một pha xử lý "decouple state" rất kinh điển, nó giúp hệ thống vừa có độ bảo mật của Stateful, lại vừa tận dụng được khả năng scale của Stateless. Thank you bạn vì đã đúc kết lại một ý rất đắt giá 🤝

Bài viết hay, lúc mình mới tìm hiểu về auth thì k có mấy bài được như vầy. Ngoài ra mình có góp ý nhỏ là 1 hệ thống không phải hoàn toàn là stateless hay stateful, mà có 1 mức độ nào đó. Đó cũng là ưu điểm của JWT so với opaque token, vì opaque token bắt buộc phải có session (stateful), nhưng JWT có thể linh hoạt được phần nào cần stateful phần nào không.

nice

Getting Business Central up and running is a marathon, not a sprint, so definitely don't skip the data cleaning phase. It requires serious focus and strategy, similar to staying sharp in a match of 1v1 lol , but the organized workflows are totally worth the effort!