Sorrry cả nhà giọng mình hơi ề à hơi ngáo vì lúc đó hơi mệt :(. Có một vài điều cần lưu ý: - Regex replace base64url thiếu “global”, đúng là /\+/g, /\//g (thay bằng _ chứ không phải -) và /\=/g. Trong video mình bị nhầm. - Các vấn đề liên quan tới bảo mật token như: độ mạnh của secret key, thời hạn sống của token, blacklist, nên lưu token vào đâu cho bảo mật, v.v mình nói ở video sau nhé. - Khi sử dụng session để authentication thì gọi là "session-based authentication", còn token là "token-based authentication" nhé. ❓Tại sao "token-based authentication" với JWT hiện tại lại tỏ ra vượt trội và ưu thế hơn so vơi "session" trong các ứng dụng hiện đại ngày nay? - Đúng là cơ chế thì vẫn là luồng xác thực tương tự như session đó. Server tạo ra JWT trả về client, client lưu trữ và gửi lên cùng các request... Tuy nhiên, mấu chốt nó nằm ở việc JWT nó là stateless authentication. Đích đến vẫn là check DB, chắc chắn rồi. Nhưng nó là stateless về về mặt kiến trúc hệ thống trông như sau: [Client] -> [Web server] -> [Database] Khi dùng JWT thì [Web server] không lưu dữ liệu nữa (sessions thì được lưu ở đây), nên JWT nó là stateless authentication. Khi đó dữ liệu được lưu trong chính payload của JWT, thường lưu userID để xác định user (JWT gọi là "sub" - subject). Vậy stateless ở khúc [Web server] có lợi gì? Hãy tưởng tượng hệ thống của bạn không phải chỉ có 1 máy chủ, mà có từ 2 máy chủ trở lên, phía trước là Load balancer (cân bằng tải), nhiệm vụ chia tải cho các [Web server] phía sau. Khi đó, mỗi request của client có thể vào các máy chủ khác nhau. Giả sử login request vào máy chủ A và tạo session trên đó, request sau lại vào máy chủ B thì sẽ không có session nên sẽ lỗi Unauthorized. Giải pháp khi đó là cần sync sessions giữa các [Web server], hoặc lưu session ra DB/hoặc một nơi chung nào đó để các [Web server] cùng trỏ tới => phức tạp hơn, khó khăn khi scale hơn. Nếu dùng stateless authentication như JWT thì không gặp phải vấn đề trên nữa. Các request có thể mang JWT tới bất cứ [Web server] nào, chỉ cần có secret key là có thể xác thực được token. Ngoài ra, JWT không lo đụng chính sách CORS của trình duyệt khi authentication như với cookie (trong case sử dụng session). Nó cũng bảo mật hơn vì xác thực bằng secret key, phải có secret key mới có thể xác thực. ✅Tóm váy lại: Tại sao "token-based authentication", cụ thể là JWT lại tỏ ra vượt trội hơn? 👉 Stateless, dễ dàng mở rộng; phù hợp với kiến trúc phân tán (không cần sync session); bảo mật; cross-domain/origin (không dính CORS khi authentication); tùy biến cao (payload mang data).
Really appreciate anh. Những kiến thức a chia sẻ luôn luôn bài bản, chi tiết, rõ ràng và nó thực sự giúp ít rất nhiều trong con đường sự nghiệp của e ạ.
video hay quá, đã xem hết 3 video trong series này mà thực sự bổ ích cho 1 người làm FE như e, mong anh ra tiếp các phần sau của series này.
Việc tự học rất quan trọng nhưng có 1 ông thầy siêu vip pro như a Sơn thì vẫn là 1 sự may mắn. Có những cái mà a không nói thì cho tự học cả đời cũng chả biết đến sự tồn tại của nó :))
Cảm ơn e đã em nhiều nha. Mà anh ko cao siêu vậy đâu ý. Những cái này bình thường có thể một số anh em ko thích tìm hiểu thôi, chứ ngồi vọc thì một lúc cũng biết em nè
Hi anh Sơn, em theo dõi anh qua các bài nodejs từ 2021, lúc đó em chưa tốt nghiệp. Khoảng thời gian đó em đi làm ở công ty viễn thông F về laravel. 2023 em phải đi NVQS nên đành gác lại công việc. Dạo gần đây em có hỏi thăm các bạn học chung và xem các trang tuyển dụng về vị trí laravel thì thấy thị trường ảm đạm quá nên em tiếp tục học thêm về nodejs. Anh có thể ra một chuỗi video làm một dự án thực tế về nodejs được không ạ, em cảm ơn anh nhiều🎉❤
Cảm ơn em đã ủng hộ F8. Hiện tại anh đang khá bận việc khác nên chưa thể ra chuỗi video sớm được em ạ. Em tìm TrungQuanDev xem, anh thấy bạn ấy có một chuỗi về Node Express hay đó em ơi.
Hay quá đi mất. Anh cho em hỏi làm sao anh biết những quy trình bài bản thế này ngoài việc đọc thật kỹ tài liệu chính thống của bên cung cấp công nghệ ạ? Em tuy rất thích ứng dụng nhưng việc đọc thật kỹ tài liệu hướng dẫn từ các bên cung cấp vẫn là thứ mà em chưa thể tận hưởng được. Chính vì thế em rất thích các video hướng dẫn và giải thích cụ thể như kênh của anh ấy ạ.
Có nhiều bài viết em ơi, ví dụ khi em tìm cách sử dụng JWT thì em hãy tìm thêm với từ khóa "... without library" (không sử dụng thư viện) chẳng hạn. Ngoài ra, search thêm hình ảnh "... workflow" để tìm hiểu luồng thông qua hình ảnh.
Anh ơi cho em hỏi với ạ, em muốn export cơ sở dữ liệu trong mongodb, em tìm trên mạng thì thấy hướng dẫn bằng command mongodump, nhưng em cài mongodb 6.0 thì k thấy có mongodump, anh có thể hướng dẫn em cách export dữ liệu được k ạ
Được nha em, nhưng làm vậy thì không cần dùng JWT nữa. Vì cách làm như em nói thì lưu token trong DB, nên không cần lưu dữ liệu trong token như JWT nữa. Tùy vào từng bài toán thì mình lựa chọn cách xài cho phù hợp thôi em ạ. Như JWT thì nó có thể dùng xác thực tính hợp lệ thôi (không cần phải xác thực người dùng, tình huống đó thậm chí không cần query vào DB). Còn tình huống lưu token vào DB thì bắt buộc phải query để xác thực và thiết kế DB chỗ đó cũng phức tạp hơn JWT (nó đẩy data vào payload rồi nên server hay DB không phải lưu), dù tình huống không thực sự cần làm vậy => tăng tải server hơn.
chao a va moi nguoi . cho e hoi: ví dụ nếu res.render('home',{userData}) co cach nao de header o partials cung nhan duoc userData khong a . e muon kiem tra neu nguoi dung dang nhap thi se hien thi logout
Anh cho em hỏi 2 câu hỏi mong anh cho e xin ý kiến ạ. Nếu câu hỏi em có sai sót mong anh bỏ qua😁 Em cảm ơn nhiều ạ ^^ 1) Em dùng kiểu session để lưu token vào database, thì mình có thể giải quyết vấn đề scale ngang, nhưng sẽ dẫn đến vấn đề tốc độ xử lý chậm vì phải xuống db check mỗi lần đăng nhập(hay vào một private route), với nhiều user thì làm nặng db. Em nghĩ như thế có đúng không anh? 2) Em mới tìm hiểu về jwt chưa có kiến thức nhiều, vì jwt là stateless thì giả sử trong trường hợp server một đăng xuất một người dùng nào đó thì làm sao ạ? Giả sử mình lưu jwt ở cookie rồi dùng res.clearCookie ở server thì ổn không anh? Giả sử mình lưu thêm refresh token(stateful) rồi hạ thời gian valid của accesstoken xuống, rồi xoá refresh token ở server thì cũng không thể nào làm logout ngay lập tức được đúng không anh? Không biết mình có cách khắc phục nào không ạ?
Hi em, 1. Việc em dùng JWT để authentication lợi hơn so với việc lưu session ở DB ở điểm là JWT nó tối ưu hiệu năng hơn, trường hợp token không hợp lệ thì nó check ở middleware và không cần chọc vào DB, token hợp lệ nó mới chọc vào DB thôi; còn session lưu DB thì dù đúng/sai vẫn cần chọc vào DB để check. 2. Nếu theo lý thuyết JWT và xài theo stateless thì server không lưu trạng thái của user nên server không đăng xuất được user đâu. Kể cả em có xoá token ở client thì chỉ đăng xuất ở trình duyệt đó; nếu token bị lộ thì nó vẫn xài được cho tới khi tới exp; vì JWT ký theo cách đó em chỉ có cách tới tương lai để nó hết hạn thôi. Đúng như em nói, em để exp access token thấp và xài refresh token (stateful) thì em xoá refresh token đi sau đó ngồi chờ access token hết hạn thì user mới đăng xuất. Vì vậy, để xử lý triệt để hơn thì đầu tiên tạo blacklist cho access token trên server (lại thành stateful), viết thêm API logout và push access token vào blacklist (có thể lưu vào Redis với exp bằng thời gian còn lại của access token), ở bước verify thì check cả xem access token có trong blacklist hay không. Khi server muốn đăng xuất user nào thì có thể xoá refresh token đồng thời bắn websocket* về cho client gọi logout để đưa access token vào blacklist. Việc này gọi là thu hồi token (revoke), vì JWT mình không làm cho nó hết hạn được (ngoài ngồi chờ). Một số người họ chỉ xoá token ở client đi thôi. Làm vậy token bị lộ vẫn xài được cho tới khi hết hạn. Nên với hệ thống yêu cầu bảo mật hơn thì em có thể áp dụng cách trên nhé. Nói chung còn tuỳ vào từng yêu cầu bảo mật của mỗi hệ thống, nếu em có yêu cầu cụ thể thì nói cụ thể hơn anh em bàn tiếp nhé. *Xài websocket chỉ có ý nghĩa khi user đang mở web trên trình duyệt thôi, nếu đang offline hoặc lỗi connect websocket thì không được. Nên em có thể check xem user có còn refresh token hay không, khi truy cập trở lại mà access token còn hạn nhưng refresh token không còn thì có thể xử lý cho user đăng xuất nhé.
Blacklist đơn giản là "danh sách đen", các tokens trong danh sách này dù còn hạn nhưng cũng được coi là không hợp lệ. Còn lưu ra redis nó chỉ là một lựa chọn thôi em ạ (cho nhanh, và có thể đặt expires), còn mình vẫn lưu ra nơi khác như file, db, v.v tùy từng bài toán nha em.
Em có 1 câu hỏi là khi mình sign và verify thì em dùng khóa bất đối xứng. Thì anh nghỉ mình nên generate nó trong code hay mình tạo rồi gắn trong .env ạ
Config thì nên đưa ra env em nhé. Không cần phải là khoá bất đối xứng, mà config nói chung cho dự án cũng nên đưa ra env. Bản thân một dự án có nhiều môi trường khi phát triển: dev, staging, UAT, production. Đưa ra env giúp dễ dàng cấu hình khác nhau giữa các môi trường, và cũng bảo mật hơn khi có thể ignore các file env mà không đẩy lên Git em nhé.
Bạn cho hỏi: mình tạo một webserver độc lập, khi login thì sẽ chạy sang một server khác để kiểm tra, nếu đúng thì sẽ trả lại một token. Ví dụ: mình viết 1 web cho login bằng google, đương nhiên login bằng google thì sẽ được hướng dẫn cách thực hiện và có thư viện nhưng ở đây website cho login cũng là tự viết, chỉ biết là trả lại một token. Vậy mình làm sao biết token đấy là chính xác? Tất nhiên khi gọi login thì vẫn truyền theo các biến được quy định riêng. Tôi có đọc 1 tài liệu trên trang Microsoft, họ dạy cách sau khi giải mã token được payload thì sẽ so sánh các biến trong payload với các biến truyền vào lúc gọi login. Cách này thì vẫn lưu session thôi nhưng được cái người dùng sẽ chỉ nhớ 1 mật khẩu cho các trang web khác nhau. Trong mỗi csdl của 1 trang web vẫn có bảng user để phục vụ phân quyền. Tôi thấy cách này hợp lý do các trang web ko phải đều phát triển từ đầu và do nhiều nhà phát triển khác nhau.
Chào bạn, khi bạn có nhiều web server và sử dụng một web server để cấp phát token thì server đó gọi là Authorization server, con này chỉ để cấp phát token (cả trường hợp refresh token) thôi. Còn ở các web server khác để verify được token thì bạn sẽ share JWT_SECRET key ở các server đó nữa, nhưng làm vậy thì rủi ro lộ key sẽ cao hơn, và khi lộ attacker có thể tự generate token hợp lệ. Cách xử lý trong thực tế là thay vì dùng khóa đối xứng (một khóa vừa cấp phát vừa xác thực token) thì bạn dùng khóa bất đối xứng, ví dụ RSA. Tại Auth server bạn lưu Private key để cấp phát token thôi, và share Public key tới các server cần xác thực. Public key chỉ có thể xác thực được token mà không tạo được token mới bạn nhé. Một cách nữa là thay vì share public key như trên, thì sau khi Auth server cấp phát token, đứng từ bên web server khác bạn dùng token đó gọi sang Auth server để xác thực. Sau khi xác thực thành công, thì từ web server đó vẫn cần query vào DB để lấy ra thông tin user tương ứng bạn nha. Có thể các web server đều dùng chung một bảng users trong DB, hoặc cũng có thể sau khi xác thực thì call API sang Auth server để lấy thông tin user, hoặc cũng có thể mỗi trang có một DB users riêng và sync users data từ Auth server, hoặc cũng có thể sau khi xác thực bạn lại tự đăng ký một user với trong DB riêng của mỗi trang web, ánh xạ 1-1 giữa UserID từ Auth server với UserID của DB riêng của trang web. Nói chung nó tùy vào từng trường hợp cụ thể mà ta có cách xử lý khác nhau bạn ạ.
@@thuytruongluu3669 Nếu cùng một hệ thống do ta tự xây dựng thì việc share public key cho các web server tự check token là một giải pháp hiệu quả và an toàn bạn nhé.
@@F8VNOfficial vâng, nhưng như tôi đã nói, do nhiều bên xây dựng, thời gian phát triển cũng ko giống nhau. Ở đây các hệ thống sau chỉ thừa hưởng chức năng nhập và quản lý người dùng của hệ thống trước (mục đích để người dùng đỡ phải dùng nhiều tài khoản) nên giải pháp thực tế là check token là hợp lý. Khi đăng nhập lần đầu sẽ tạo luôn người dùng để phục vụ phân quyền riêng cho từng hệ thống.
@@F8VNOfficial em muốn tìm hiểu về cơ chế với cách triển khai hệ thống caching để tối ưu thời gian gọi data ấy anh hoặc anh làm về docker để chạy services cũng hay ạ
@@dungvu-fm8uq do ổng bận cộng thêm quả anh em mong chờ nên làm quả khoá java pro chất lượng hơn so với ban đầu (bạn xem live hôm trước sẽ thấy ổng nói câu này) . khoá pro thông báo sẽ lên lịch pre-order vào tháng 6 rồi. (Nhưng chắc chỉ đc 50% quá trình thôi vì ổng sơn cũng có nói khoá vẫn chưa hoàn thiện toàn bộ)
@@ienMeo-vj7rp mình nhắn tin hỏi admin thì bạn ấy nói là chưa có kế hoạch gì cả, đợi thông báo chính thức từ anh Sơn ý (Vì lần này đợi xong 80-90% mới cho pre order cơ).
@@HaChritian À do mình nhầm comment của anh ấy, tưởng ổng là người của F8 ai ngờ là hội viên, bây giờ chỉ biết ngồi chờ vậy. Xem anh tháng này đưa ra thông báo gì.
Nó là tiêu chuẩn authentication, ví dụ với xác thực cơ bản (Basic Auth) thì sẽ gửi tiêu đề với Authorization: Basic , với token thì nó là Authorization: Bearer , tức nó là tuân theo tiêu chuẩn để phân biệt các hình thức Authorization. Nếu em không gửi kèm Bearer cũng được thôi, nhưng gửi như vậy thì không cụ thể là em đang dùng chuẩn nào. Em có thể tìm hiểu thêm qua từ khóa "Http Header Authorization" nhé.
Em chào anh, em thắc mắc là sao khi anh thay thế/bỏ các kí tự đặc biệt rồi khi anh giải mã ra thì nó vẫn giải mã được ạ? Ví dụ trong bài anh encodedHeader ra "abc=" sau khi anh bỏ dấu '=' đi thì còn "abc". Vậy sao khi giải mã ra nó vẫn ra đúng cái object ban đầu anh nhỉ? (Em xin lỗi nếu câu hỏi của em hơi ngớ ngẫn hoặc em bị miss phần nào đó)
À vì đó là base64url nha em, tức là để hợp lệ việc lưu base64 vào cookie hoặc truyền nó qua URL param thì người ta cho phép chuyển đổi như vậy nha em, mục đích là để an toàn cho URL và cookie và vẫn là base64 hợp lệ.
Cách chuyển sang base64url: - Chuyển + thành - - Chuyển / thành _ - Xóa bỏ dấu = đây em nhé. Đừng thay thế theo cách khác, như thế nó sẽ không hợp lệ nữa.
Anh nghĩ đã là web developer thì sớm muộn cũng phải học em ạ. Ban đầu có thể với FE chỉ cần biết cách nhận, lưu trữ và hiểu về bảo mật token là được. Có thời gian cũng nên tìm hiểu xem nó hoạt động thế nào, tại sao nó lại bảo mật nha em.
Thông tin công khai mà em. Lộ cũng không sao, em đừng đưa thông tin nhạy cảm vào đó là được. Có signature thì token đâu có fake được, trừ phi em để lộ secret thôi.
và anh cho em hỏi là, JWT là để duy trì đăng nhập vậy có trường hợp nào mà user đã đăng nhập mà payload và header bị thay đổi dẫn đến ko thể tạo đc token mới để gian hạn không ạ, em cám ơn ạ
mk thấy sesionID của cookie và jwtSecket của jwt có khác gì nhau đâu nhỉ. đều lưu bí mật ở đâu đó. và khi backend nhận request từ api thì đều cần tới 2 thằng bí mật kia để so sánh => xác thực. thế thì jwt có lợi gì hơn so với cookie vậy mọi người. ai đó đọc đc giải thích hộ mk với ạ. mk cảm ơn
Sorrry cả nhà giọng mình hơi ề à hơi ngáo vì lúc đó hơi mệt :(. Có một vài điều cần lưu ý:
- Regex replace base64url thiếu “global”, đúng là /\+/g, /\//g (thay bằng _ chứ không phải -) và /\=/g. Trong video mình bị nhầm.
- Các vấn đề liên quan tới bảo mật token như: độ mạnh của secret key, thời hạn sống của token, blacklist, nên lưu token vào đâu cho bảo mật, v.v mình nói ở video sau nhé.
- Khi sử dụng session để authentication thì gọi là "session-based authentication", còn token là "token-based authentication" nhé.
❓Tại sao "token-based authentication" với JWT hiện tại lại tỏ ra vượt trội và ưu thế hơn so vơi "session" trong các ứng dụng hiện đại ngày nay?
- Đúng là cơ chế thì vẫn là luồng xác thực tương tự như session đó. Server tạo ra JWT trả về client, client lưu trữ và gửi lên cùng các request... Tuy nhiên, mấu chốt nó nằm ở việc JWT nó là stateless authentication.
Đích đến vẫn là check DB, chắc chắn rồi. Nhưng nó là stateless về về mặt kiến trúc hệ thống trông như sau:
[Client] -> [Web server] -> [Database]
Khi dùng JWT thì [Web server] không lưu dữ liệu nữa (sessions thì được lưu ở đây), nên JWT nó là stateless authentication. Khi đó dữ liệu được lưu trong chính payload của JWT, thường lưu userID để xác định user (JWT gọi là "sub" - subject).
Vậy stateless ở khúc [Web server] có lợi gì? Hãy tưởng tượng hệ thống của bạn không phải chỉ có 1 máy chủ, mà có từ 2 máy chủ trở lên, phía trước là Load balancer (cân bằng tải), nhiệm vụ chia tải cho các [Web server] phía sau.
Khi đó, mỗi request của client có thể vào các máy chủ khác nhau. Giả sử login request vào máy chủ A và tạo session trên đó, request sau lại vào máy chủ B thì sẽ không có session nên sẽ lỗi Unauthorized. Giải pháp khi đó là cần sync sessions giữa các [Web server], hoặc lưu session ra DB/hoặc một nơi chung nào đó để các [Web server] cùng trỏ tới => phức tạp hơn, khó khăn khi scale hơn.
Nếu dùng stateless authentication như JWT thì không gặp phải vấn đề trên nữa. Các request có thể mang JWT tới bất cứ [Web server] nào, chỉ cần có secret key là có thể xác thực được token.
Ngoài ra, JWT không lo đụng chính sách CORS của trình duyệt khi authentication như với cookie (trong case sử dụng session). Nó cũng bảo mật hơn vì xác thực bằng secret key, phải có secret key mới có thể xác thực.
✅Tóm váy lại: Tại sao "token-based authentication", cụ thể là JWT lại tỏ ra vượt trội hơn?
👉 Stateless, dễ dàng mở rộng; phù hợp với kiến trúc phân tán (không cần sync session); bảo mật; cross-domain/origin (không dính CORS khi authentication); tùy biến cao (payload mang data).
Rất hi vọng a sớm giải thích thêm về vấn đề lưu trữ token, blacklist và đặc biệt là refresh token ạ!
A giải thích cuốn thế ạ. Mong a chia sẻ thêm nhiều về auth
Really appreciate anh. Những kiến thức a chia sẻ luôn luôn bài bản, chi tiết, rõ ràng và nó thực sự giúp ít rất nhiều trong con đường sự nghiệp của e ạ.
Cảm ơn em nhiều nha. Chúc em gặt hái nhiều thành quả.
nhiều khóa học trên mạng thì em vẫn phải công nhận là anh sơn idol nói dễ hiểu và muốn nghe nhất ^^😊
Cảm ơn em nhiều nha
Trước giờ toàn dùng thư viện nên cũng không để ý bên trong nó tư duy như thế nào, nay xem clip của anh Sơn nên hiểu hơn.
video hay quá, đã xem hết 3 video trong series này mà thực sự bổ ích cho 1 người làm FE như e, mong anh ra tiếp các phần sau của series này.
Em thấy video này lâu rồi mà nay mới có thời gian xem, nội dung rất hay và hữu ích để hiểu về cơ chế hoạt động của jwt
Việc tự học rất quan trọng nhưng có 1 ông thầy siêu vip pro như a Sơn thì vẫn là 1 sự may mắn. Có những cái mà a không nói thì cho tự học cả đời cũng chả biết đến sự tồn tại của nó :))
Cảm ơn e đã em nhiều nha. Mà anh ko cao siêu vậy đâu ý. Những cái này bình thường có thể một số anh em ko thích tìm hiểu thôi, chứ ngồi vọc thì một lúc cũng biết em nè
😂😂😂😂
Video rất hay và bổ ích ạ, a có thể làm thêm về flow của access token và refresh token bên phần frontend được không ạ
Để anh sắp xếp nhé
anh làm một khoá về bảo mật web và chống lại các cuộc tấn công web được không anh
ai muốn sếp làm video về refresh token cho mình xin 1 like
anh không ra thêm video về phần này nữa ạ? Như SSO hay nhiều thứ khác ấy ạ?
Hóng video refresh token, bảo mật token tiếp theo.
Bao giờ có khóa nextjs vậy anh. Hóng quá
hóng anh Sơn làm thêm về vấn đề lưu token ở đâu
Vẫn chưa có khoá học mới ạ anh. em hóng các khoá mới của anh quá.
Anh thật là người có tâm. Cảm ơn anh nhìu ❤
a làm thêm về refreshToken đi a, dễ hiểu quá a ạ :)))
Xịn quá a ơi mong a làm tiếp về những cái liên quan tới jwt ạ
Mong anh ra nhanh về vấn đề bảo mật token ở phía client đó ạ
hay quá! có thời gian làm thêm quả refresh token luôn cho trọn bộ a :))
Hi anh Sơn, em theo dõi anh qua các bài nodejs từ 2021, lúc đó em chưa tốt nghiệp. Khoảng thời gian đó em đi làm ở công ty viễn thông F về laravel. 2023 em phải đi NVQS nên đành gác lại công việc. Dạo gần đây em có hỏi thăm các bạn học chung và xem các trang tuyển dụng về vị trí laravel thì thấy thị trường ảm đạm quá nên em tiếp tục học thêm về nodejs. Anh có thể ra một chuỗi video làm một dự án thực tế về nodejs được không ạ, em cảm ơn anh nhiều🎉❤
Cảm ơn em đã ủng hộ F8. Hiện tại anh đang khá bận việc khác nên chưa thể ra chuỗi video sớm được em ạ. Em tìm TrungQuanDev xem, anh thấy bạn ấy có một chuỗi về Node Express hay đó em ơi.
Hay sếp ơi. Đang viết lại hệ thống BE thì xem đc video này😊😊😊
Khi nào mới có video làm tiếp dự án tiktok ui vậy anh? Em chỉ xem tới phần sidebar thì không tìm thấy video phần tiếp theo
anh ơi khóa JS Pro sắp ra chưa ạ chứ em sắp chuyển nghề đến nơi rồi
Khi nào khóa JavaScripts Pro ra mắt thế a Sơn ơi, e mong ngóng từng ngày
Hay quá đi mất. Anh cho em hỏi làm sao anh biết những quy trình bài bản thế này ngoài việc đọc thật kỹ tài liệu chính thống của bên cung cấp công nghệ ạ? Em tuy rất thích ứng dụng nhưng việc đọc thật kỹ tài liệu hướng dẫn từ các bên cung cấp vẫn là thứ mà em chưa thể tận hưởng được. Chính vì thế em rất thích các video hướng dẫn và giải thích cụ thể như kênh của anh ấy ạ.
Có nhiều bài viết em ơi, ví dụ khi em tìm cách sử dụng JWT thì em hãy tìm thêm với từ khóa "... without library" (không sử dụng thư viện) chẳng hạn. Ngoài ra, search thêm hình ảnh "... workflow" để tìm hiểu luồng thông qua hình ảnh.
anh làm thêm refresh token dựa vào code video được không ạ
Okie em nha
a sơn cho hỏi dạo này các video pro sao nó tải chậm vậy , đang học lúc nào cũng bị gián đoạn
Quá hay a ơi, mong a ra video tiếp theo ngay bây giờ ạ
Cho em hỏi là khi nào mình ra khoá NextJS vậy ạ
Hóng video mới của seriea này.
ra video phần đăng nhập bằng Facebook, Github .... đi anh ôi
Hóng SSO anh ơi và mirco server la gì nữa anh ơi
Rảnh anh sẽ làm em nha
video rất hay và bổ ích, hy vọng anh sẽ ra thêm nhiều video như này
Okie em nha
rất hay
Ra seri Vue 3 đi F8
làm khóa học vuejs anh ơi
anh ơi anh ra clip về SSO đi ạ
Anh ơi cho em hỏi với ạ, em muốn export cơ sở dữ liệu trong mongodb, em tìm trên mạng thì thấy hướng dẫn bằng command mongodump, nhưng em cài mongodb 6.0 thì k thấy có mongodump, anh có thể hướng dẫn em cách export dữ liệu được k ạ
xong khoá này rồi, anh cho em luôn 1 video về SSO được không ạ =))
Okie em rảnh anh làm thêm nha
Lưu token trực tiếp vào DB rồi so sánh với request dc k v a
Được nha em, nhưng làm vậy thì không cần dùng JWT nữa. Vì cách làm như em nói thì lưu token trong DB, nên không cần lưu dữ liệu trong token như JWT nữa. Tùy vào từng bài toán thì mình lựa chọn cách xài cho phù hợp thôi em ạ. Như JWT thì nó có thể dùng xác thực tính hợp lệ thôi (không cần phải xác thực người dùng, tình huống đó thậm chí không cần query vào DB). Còn tình huống lưu token vào DB thì bắt buộc phải query để xác thực và thiết kế DB chỗ đó cũng phức tạp hơn JWT (nó đẩy data vào payload rồi nên server hay DB không phải lưu), dù tình huống không thực sự cần làm vậy => tăng tải server hơn.
chao a va moi nguoi . cho e hoi: ví dụ nếu res.render('home',{userData}) co cach nao de header o partials cung nhan duoc userData khong a . e muon kiem tra neu nguoi dung dang nhap thi se hien thi logout
em chào anh sơn ạ, anh ơi cho em hỏi là khoá React Js của bên f8 mình chưa hoàn thiện ạ
Anh cho em hỏi 2 câu hỏi mong anh cho e xin ý kiến ạ. Nếu câu hỏi em có sai sót mong anh bỏ qua😁 Em cảm ơn nhiều ạ ^^
1) Em dùng kiểu session để lưu token vào database, thì mình có thể giải quyết vấn đề scale ngang, nhưng sẽ dẫn đến vấn đề tốc độ xử lý chậm vì phải xuống db check mỗi lần đăng nhập(hay vào một private route), với nhiều user thì làm nặng db. Em nghĩ như thế có đúng không anh?
2) Em mới tìm hiểu về jwt chưa có kiến thức nhiều, vì jwt là stateless thì giả sử trong trường hợp server một đăng xuất một người dùng nào đó thì làm sao ạ? Giả sử mình lưu jwt ở cookie rồi dùng res.clearCookie ở server thì ổn không anh? Giả sử mình lưu thêm refresh token(stateful) rồi hạ thời gian valid của accesstoken xuống, rồi xoá refresh token ở server thì cũng không thể nào làm logout ngay lập tức được đúng không anh? Không biết mình có cách khắc phục nào không ạ?
Hi em,
1. Việc em dùng JWT để authentication lợi hơn so với việc lưu session ở DB ở điểm là JWT nó tối ưu hiệu năng hơn, trường hợp token không hợp lệ thì nó check ở middleware và không cần chọc vào DB, token hợp lệ nó mới chọc vào DB thôi; còn session lưu DB thì dù đúng/sai vẫn cần chọc vào DB để check.
2. Nếu theo lý thuyết JWT và xài theo stateless thì server không lưu trạng thái của user nên server không đăng xuất được user đâu. Kể cả em có xoá token ở client thì chỉ đăng xuất ở trình duyệt đó; nếu token bị lộ thì nó vẫn xài được cho tới khi tới exp; vì JWT ký theo cách đó em chỉ có cách tới tương lai để nó hết hạn thôi.
Đúng như em nói, em để exp access token thấp và xài refresh token (stateful) thì em xoá refresh token đi sau đó ngồi chờ access token hết hạn thì user mới đăng xuất.
Vì vậy, để xử lý triệt để hơn thì đầu tiên tạo blacklist cho access token trên server (lại thành stateful), viết thêm API logout và push access token vào blacklist (có thể lưu vào Redis với exp bằng thời gian còn lại của access token), ở bước verify thì check cả xem access token có trong blacklist hay không. Khi server muốn đăng xuất user nào thì có thể xoá refresh token đồng thời bắn websocket* về cho client gọi logout để đưa access token vào blacklist. Việc này gọi là thu hồi token (revoke), vì JWT mình không làm cho nó hết hạn được (ngoài ngồi chờ).
Một số người họ chỉ xoá token ở client đi thôi. Làm vậy token bị lộ vẫn xài được cho tới khi hết hạn. Nên với hệ thống yêu cầu bảo mật hơn thì em có thể áp dụng cách trên nhé. Nói chung còn tuỳ vào từng yêu cầu bảo mật của mỗi hệ thống, nếu em có yêu cầu cụ thể thì nói cụ thể hơn anh em bàn tiếp nhé.
*Xài websocket chỉ có ý nghĩa khi user đang mở web trên trình duyệt thôi, nếu đang offline hoặc lỗi connect websocket thì không được. Nên em có thể check xem user có còn refresh token hay không, khi truy cập trở lại mà access token còn hạn nhưng refresh token không còn thì có thể xử lý cho user đăng xuất nhé.
@@F8VNOfficial ohh em cảm ơn anh nhiều ạ☺️☺️ em hiểu hơn rồi, anh trả lời tận tình quá em cảm ơn rất nhiều 😊🙏🙏
Mình thấy jwt có hàm .sign để tạo token mà bạn sao mình phải tạo token thủ công như này vậy ? Bảo mật hơn hả bạn ?
làm thủ công để hiểu bản chất mà bạn
video sao sẵn nói về blacklist sử dụng redis đi a
Blacklist đơn giản là "danh sách đen", các tokens trong danh sách này dù còn hạn nhưng cũng được coi là không hợp lệ. Còn lưu ra redis nó chỉ là một lựa chọn thôi em ạ (cho nhanh, và có thể đặt expires), còn mình vẫn lưu ra nơi khác như file, db, v.v tùy từng bài toán nha em.
@@F8VNOfficial tại sao lại cần đưa nó vào blacklist khi vẫn còn thời hạn v anh? để revoke nó khi cần đúng không anh?
Rã đông đi anh ơi...
Mong anh làm về single sign on
Okie em nha
vẫn mãi đợi JS pro
Em có 1 câu hỏi là khi mình sign và verify thì em dùng khóa bất đối xứng. Thì anh nghỉ mình nên generate nó trong code hay mình tạo rồi gắn trong .env ạ
Config thì nên đưa ra env em nhé. Không cần phải là khoá bất đối xứng, mà config nói chung cho dự án cũng nên đưa ra env. Bản thân một dự án có nhiều môi trường khi phát triển: dev, staging, UAT, production. Đưa ra env giúp dễ dàng cấu hình khác nhau giữa các môi trường, và cũng bảo mật hơn khi có thể ignore các file env mà không đẩy lên Git em nhé.
Hôm nay a giống e, đều ngủ sớm :))
2-3h sáng sớm đi ngủ là ngủ sớm ý hả :)))
Bạn cho hỏi: mình tạo một webserver độc lập, khi login thì sẽ chạy sang một server khác để kiểm tra, nếu đúng thì sẽ trả lại một token. Ví dụ: mình viết 1 web cho login bằng google, đương nhiên login bằng google thì sẽ được hướng dẫn cách thực hiện và có thư viện nhưng ở đây website cho login cũng là tự viết, chỉ biết là trả lại một token. Vậy mình làm sao biết token đấy là chính xác? Tất nhiên khi gọi login thì vẫn truyền theo các biến được quy định riêng. Tôi có đọc 1 tài liệu trên trang Microsoft, họ dạy cách sau khi giải mã token được payload thì sẽ so sánh các biến trong payload với các biến truyền vào lúc gọi login. Cách này thì vẫn lưu session thôi nhưng được cái người dùng sẽ chỉ nhớ 1 mật khẩu cho các trang web khác nhau. Trong mỗi csdl của 1 trang web vẫn có bảng user để phục vụ phân quyền. Tôi thấy cách này hợp lý do các trang web ko phải đều phát triển từ đầu và do nhiều nhà phát triển khác nhau.
Chào bạn, khi bạn có nhiều web server và sử dụng một web server để cấp phát token thì server đó gọi là Authorization server, con này chỉ để cấp phát token (cả trường hợp refresh token) thôi. Còn ở các web server khác để verify được token thì bạn sẽ share JWT_SECRET key ở các server đó nữa, nhưng làm vậy thì rủi ro lộ key sẽ cao hơn, và khi lộ attacker có thể tự generate token hợp lệ.
Cách xử lý trong thực tế là thay vì dùng khóa đối xứng (một khóa vừa cấp phát vừa xác thực token) thì bạn dùng khóa bất đối xứng, ví dụ RSA. Tại Auth server bạn lưu Private key để cấp phát token thôi, và share Public key tới các server cần xác thực. Public key chỉ có thể xác thực được token mà không tạo được token mới bạn nhé.
Một cách nữa là thay vì share public key như trên, thì sau khi Auth server cấp phát token, đứng từ bên web server khác bạn dùng token đó gọi sang Auth server để xác thực.
Sau khi xác thực thành công, thì từ web server đó vẫn cần query vào DB để lấy ra thông tin user tương ứng bạn nha. Có thể các web server đều dùng chung một bảng users trong DB, hoặc cũng có thể sau khi xác thực thì call API sang Auth server để lấy thông tin user, hoặc cũng có thể mỗi trang có một DB users riêng và sync users data từ Auth server, hoặc cũng có thể sau khi xác thực bạn lại tự đăng ký một user với trong DB riêng của mỗi trang web, ánh xạ 1-1 giữa UserID từ Auth server với UserID của DB riêng của trang web.
Nói chung nó tùy vào từng trường hợp cụ thể mà ta có cách xử lý khác nhau bạn ạ.
@@F8VNOfficial ok, xin cám ơn. Tôi nghĩ cách thực tế vẫn là check token.
@@thuytruongluu3669 Nếu cùng một hệ thống do ta tự xây dựng thì việc share public key cho các web server tự check token là một giải pháp hiệu quả và an toàn bạn nhé.
@@F8VNOfficial vâng, nhưng như tôi đã nói, do nhiều bên xây dựng, thời gian phát triển cũng ko giống nhau. Ở đây các hệ thống sau chỉ thừa hưởng chức năng nhập và quản lý người dùng của hệ thống trước (mục đích để người dùng đỡ phải dùng nhiều tài khoản) nên giải pháp thực tế là check token là hợp lý. Khi đăng nhập lần đầu sẽ tạo luôn người dùng để phục vụ phân quyền riêng cho từng hệ thống.
anh làm về redis với elasticsearch đi anh:D
Cụ thể hơn thì bài toán của em là gì em nhỉ
@@F8VNOfficial em muốn tìm hiểu về cơ chế với cách triển khai hệ thống caching để tối ưu thời gian gọi data ấy anh
hoặc anh làm về docker để chạy services cũng hay ạ
anh ơi, bên F8 còn ra khóa JS Pro nữa không ạ?
Có nhé bạn, có thông báo chuẩn bị sắp ra mắt rồi (trong khoá html/css pro mới thấy thông báo này)
@@ienMeo-vj7rp thông báo là JavaScript Pro (dự kiến Pre-Order cuối năm 2023) nhưng giờ qua được nửa năm 2024 rồi vẫn chưa thấy gì nên mình mới hỏi lại
@@dungvu-fm8uq do ổng bận cộng thêm quả anh em mong chờ nên làm quả khoá java pro chất lượng hơn so với ban đầu (bạn xem live hôm trước sẽ thấy ổng nói câu này) . khoá pro thông báo sẽ lên lịch pre-order vào tháng 6 rồi. (Nhưng chắc chỉ đc 50% quá trình thôi vì ổng sơn cũng có nói khoá vẫn chưa hoàn thiện toàn bộ)
@@ienMeo-vj7rp mình nhắn tin hỏi admin thì bạn ấy nói là chưa có kế hoạch gì cả, đợi thông báo chính thức từ anh Sơn ý (Vì lần này đợi xong 80-90% mới cho pre order cơ).
@@HaChritian À do mình nhầm comment của anh ấy, tưởng ổng là người của F8 ai ngờ là hội viên, bây giờ chỉ biết ngồi chờ vậy. Xem anh tháng này đưa ra thông báo gì.
ĐỢI MÃI MỚI THẤY ANH LAM JWT
Hay quá anh ơi
tại sao token chèn "Bearer" xong đẩy về BE lại tách bỏ nó đi ạ
Nó là tiêu chuẩn authentication, ví dụ với xác thực cơ bản (Basic Auth) thì sẽ gửi tiêu đề với Authorization: Basic , với token thì nó là Authorization: Bearer , tức nó là tuân theo tiêu chuẩn để phân biệt các hình thức Authorization. Nếu em không gửi kèm Bearer cũng được thôi, nhưng gửi như vậy thì không cụ thể là em đang dùng chuẩn nào. Em có thể tìm hiểu thêm qua từ khóa "Http Header Authorization" nhé.
Cảm ơn a ^^
Mong anh làm thêm refresh token ạ
Anh sẽ làm sớm nhé
mn cho em hỏi anh Sơn xài font gì cho vs code thế ạ
Fira code retina
Em chào anh, em thắc mắc là sao khi anh thay thế/bỏ các kí tự đặc biệt rồi khi anh giải mã ra thì nó vẫn giải mã được ạ? Ví dụ trong bài anh encodedHeader ra "abc=" sau khi anh bỏ dấu '=' đi thì còn "abc". Vậy sao khi giải mã ra nó vẫn ra đúng cái object ban đầu anh nhỉ? (Em xin lỗi nếu câu hỏi của em hơi ngớ ngẫn hoặc em bị miss phần nào đó)
À vì đó là base64url nha em, tức là để hợp lệ việc lưu base64 vào cookie hoặc truyền nó qua URL param thì người ta cho phép chuyển đổi như vậy nha em, mục đích là để an toàn cho URL và cookie và vẫn là base64 hợp lệ.
Cách chuyển sang base64url:
- Chuyển + thành -
- Chuyển / thành _
- Xóa bỏ dấu =
đây em nhé. Đừng thay thế theo cách khác, như thế nó sẽ không hợp lệ nữa.
@@F8VNOfficial Dạ vâng em cảm ơn anh ạ
Tại sao cần Bearer vậy bạn.
Nó là chuẩn authentication bạn ơi. Ví dụ như có Basic Auth là loại xác thực cơ bản, thì xác thực với token nó là Bearer bạn nhé
Ko có bearer có sao ko?
lại phải khen 🥰
Video rất hữu ích ạ
Hay quá anh ơi!
Dạ anh cho em hỏi, JWT thì frontend có cần học k ạ
Anh nghĩ đã là web developer thì sớm muộn cũng phải học em ạ. Ban đầu có thể với FE chỉ cần biết cách nhận, lưu trữ và hiểu về bảo mật token là được. Có thời gian cũng nên tìm hiểu xem nó hoạt động thế nào, tại sao nó lại bảo mật nha em.
Bao giờ ra Js pro thế anh em đợi gần 2 năm ròi😢
Sắp rồi em ơi, tháng sau nha em ơi
Hóng quá ạ
ở đoạn cuối lấy data chổ atob(payload) em bị dính cái InvalidCharacterError: Invalid character
thì fix làm sao anh
Em đọc lại comment ghim của anh để sửa lại hàm base64url cho đúng nha em.
@@F8VNOfficial cảm ơn anh
Hay quá a ơi
Cảm ơn em nha
Đầu luôn ạ, chúc anh nhiều sức khoẻ.
Cảm ơn em nha
anh cho e hỏi nếu header và payload bị lộ thì sao ạ
Thông tin công khai mà em. Lộ cũng không sao, em đừng đưa thông tin nhạy cảm vào đó là được. Có signature thì token đâu có fake được, trừ phi em để lộ secret thôi.
@@F8VNOfficial dạ anh ơi nếu trong payload mình để username và password thì khi lộ payload ra thì sẽ bị mã hóa ngược trợ lại đk ạ
và anh cho em hỏi là, JWT là để duy trì đăng nhập vậy có trường hợp nào mà user đã đăng nhập mà payload và header bị thay đổi dẫn đến ko thể tạo đc token mới để gian hạn không ạ, em cám ơn ạ
@@ThanhVo-tg9dn JWT là sau khi xác thực (tức là đã đăng nhập) mới có token mà, sao lại bỏ password vào payload nữa, là sao?
@@nguyenhuutri8389 đr bạn sau khi login thành công mới có token. Nhưng bên trong payload để useẻname và pass vẫn đc chứ
mk thấy sesionID của cookie và jwtSecket của jwt có khác gì nhau đâu nhỉ. đều lưu bí mật ở đâu đó. và khi backend nhận request từ api thì đều cần tới 2 thằng bí mật kia để so sánh => xác thực. thế thì jwt có lợi gì hơn so với cookie vậy mọi người. ai đó đọc đc giải thích hộ mk với ạ. mk cảm ơn
Bạn xem đoạn đầu chưa. JWT nó là stateless authentication, session là stateful authentication.
Dạo này thấy a mập thế
Ngồi nhiều ăn nhiều đó em 🤣
fully stolen drill rapper offcial f8s name.
Mong anh làm về Browser Caching
Quá hay a ơi