Auth: 02 - So sánh giữa cookie vs token authentication 🎉
ฝัง
- เผยแพร่เมื่อ 12 ต.ค. 2024
- Cùng mình tìm hiểu sự khác biệt giữa cookie vs token authentication nhé! 😍
Trong video này mình sẽ chia sẻ với các bạn:
✅ Flow authentication bằng cookie và token giống và khác nhau điểm nào?
✅ Hiện giờ thì người ta dùng cookie authentication hay token authentication
Hi vọng qua video ngắn này giúp các bạn nắm được cái flow cơ bản của việc authentication 😉
🌐 Link tham khảo
Slide: drive.google.c...
dzone.com/arti...
wp-rocket.me/b...
#token_authentication
#cookie_authentication
#cookie_vs_token_auth
-----
💻 Easy Frontend 🎉
Nơi kiến thức lập trình web frontend (html/css/javascript/reactjs) được chia sẻ một cách đơn giản, dễ hiểu mà đặc biệt là vui 😊 Với những tài liệu (tutorial) được biên soạn một cách kĩ lưỡng để giúp các bạn developer mới có thể nắm bắt vấn đề một cách nhanh chóng và hiệu quả. Từ đó nâng dần khả năng coding của các bạn lên theo thời gian.
❤️ Ủng hộ mình làm videos thì đóng góp tại đây nhé:
Ủng hộ tôi: unghotoi.com/e...
MoMo/ZaloPay: 0901 309 729
Kết nối với mình:
🎉 Fan page: / learn.easyfrontend
❓Group: / easyfrontend
💻Github: github.com/pau...
💼 LinkedIn: / haunguyenmn
hihi video này hơi rối não 😅
Có bạn nào xem xong rồi mà vẫn không hiểu gì hk?
cảm ơn anh :(( em đọc tài liệu nhiều lần rồi mà còn thiếu xót. xem video của anh lấp lại hết lỗ hổng
Yeah may quá, giúp bạn thông suốt được vấn đề là may mắn của mình òi. Ngon lành hehe 😍
Cố gắng mỗi video trọn vẹn 1 nội dung như video này thì rất hay. Một số video khác hay có câu cái này dài dòng để ở video khác...nghe câu này nó làm người học mông lung...
yeah cảm ơn bạn đã phản hồi nhé, mình sẽ lưu ý hơn nè hihi
Cảm ơn anh về bài giảng 😁 Nghe anh giảng vừa dễ hiểu vừa cuốn ý 😍😍
Rất hay rất dể hiểu. Thank bạn rất nhiêu!
cảm ơn bạn Trường nhiều nhé 😊
Bạn làm video rất hay, rất dễ hiểu. Cảm ơn bạn
Yeahhh cảm ơn bạn nhiều nhé 😍
Bài giảng hay quá , thanks you anh
hihi cảm ơn em nhiều nhé Dũng 😍
Anh hay làm backend ngôn ngữ nào thế, video sau có code mẫu hả anh
hi Nam, hiện thì anh hk có làm BE nha Nam 🙂Anh chỉ làm FE thôi nè hihi
Hóng anh là video thực hành cho auth
Yeah chỉ còn 1-2 videos nữa là tới rồi Min ơi, keep calm và đợi nhen hihi, tại anh dạo này sml quá, ko đi nhanh đc 😅
Lâu phải vào lại video bác hậu để ôn lại hihi
Bác xài máy nào để code vậy? Cho em xin thông tin với
hi bạn, thông tin máy tính của mình thế này nha:
Macbook Pro 2019
Screen 16 inches
RAM 16GB
SSD 512GB
Thầy ơi, Nên học React Context hay Redux hả thầy? Thầy có thể làm video về vấn đề đấy không? E cảm ơn
Trong playlist của thầy có "Học redux cơ bản 2020" nhưng e đang băn khoăn có nên học redux không? Hay chỉ cần Context là được?
phải học cả bạn à
2 cái này học nhanh lắm nên bạn học cả nhé
Khanh Pham yeah như bạn Tùng nói, em nên học nhé Khánh, vì tuỳ project, tuỳ trường hợp mà mình có thể apply tương ứng. Tuy nhiên thực tế thì đa phần dùng redux nè 😉
Dạ e cảm ơn thầy và a Tùng nhé, e sẽ học cả 2 😁
Anh ơi cho em hỏi session lưu ở RAM trên server hay ở trong DB vậy a?
hi em, cái này tuỳ nhu cầu của em thôi nhen 😉
Cơ bản là cần một nơi để lưu các session để validate các session của user, còn lưu ở đâu thì tuỳ nhu cầu của em nhé hehe
Cho mình hỏi,
Với JWT, làm thế nào để server biết Token phía Client gửi lên là Token chính xác, chưa có chỉnh sửa dưới client.
Phía server không lưu, vậy phải có cơ chế ví dụ giải mã chuỗi Token gửi lên. Sau khi giải mã sẽ check những thông tin gì nhỉ ? Chắc chắn phải check secret key.
Mong bạn giải thích giúp nha.
à em xem thêm cơ chế JWT em nhen, với secret key em có thể check đc là token đó có hợp lệ hay ko em nha, nếu nó bị chỉnh sửa thì em check valid nó sẽ trả về false á Hiệp hehe
Trong hệ thống sử dụng JWT (JSON Web Token), server có thể xác minh tính hợp lệ của token gửi từ phía client bằng cách thực hiện các bước sau:
Giải mã JWT: Server sẽ sử dụng secret key (khóa bí mật) được chia sẻ trước đó với phía client để giải mã token. Bằng cách giải mã, server có thể trích xuất thông tin từ phần payload của token.
Kiểm tra chữ ký (signature): Sau khi giải mã, server sẽ kiểm tra tính hợp lệ của chữ ký được tính toán từ phần header và payload của token. Để thực hiện việc này, server sử dụng secret key đã được chia sẻ để so sánh với chữ ký trong token. Nếu chữ ký không khớp hoặc token đã bị chỉnh sửa, server sẽ từ chối token đó.
Kiểm tra thông tin trong payload: Server có thể kiểm tra các thông tin trong phần payload của token để xác minh tính hợp lệ của nó. Các thông tin này có thể bao gồm ID người dùng, quyền truy cập, thời gian hết hạn (expiry), và các thông tin tùy chọn khác. Server có thể kiểm tra xem token có đáng tin cậy và có quyền thực hiện yêu cầu từ phía client không.
Xử lý logic ứng dụng: Sau khi xác minh tính hợp lệ của token, server có thể sử dụng các thông tin trong token để xác định quyền truy cập và thực hiện các logic ứng dụng phù hợp. Ví dụ: xác định người dùng, kiểm tra quyền truy cập, lấy thông tin từ cơ sở dữ liệu, và thực hiện các thao tác khác.
Quan trọng nhất là secret key được sử dụng để ký và giải mã token. Vì vậy, đảm bảo rằng secret key được bảo mật tốt và chỉ chia sẻ giữa server và phía client tin cậy. Bằng cách giữ secret key bí mật, server có thể xác minh tính toàn vẹn và tính hợp lệ của token gửi từ phía client.
Hmmm v nếu làm app quản lý như cms thì nên jwt hay cookie anh. Vì xét bảo mật có vẻ cookie bảo mật hơn và nó chặn việc crossdomain nữa hmmmmmmm
hi Hào, cái này thì mình cũng hk có nhiều kinh nghiệm lắm để đánh giá việc này, còn hiện tại theo những gì mình làm thì jwt là đủ òi nè.
Giới hạn token chỉ có hiệu lực 2 tiếng, rồi làm cơ chế refresh token.
Làm việc này thì có thể phát triển cả web, cả app, cả hệ thống khác, còn cookie thì apply được cho web thôi nè.
Đó là theo mình biết thôi hen, còn tuỳ dự án, tuỳ team có thể trao đổi với nhau để chọn một phương pháp phù hợp hen. 😉
Dạ cảm ơn câu trả lời của anh. Tại em cũng muốn làm một project nhỏ cho bản thân mà đang phân vân cơ chế login hihi. Video anh hay lắm. Sau này rảnh anh làm các tut video theo quy trình anh làm việc ở công ty để em tham khảo với :v em vẫn chưa biết quy trình làm một sản phẩm ở một công ty chuyên nghiệp như thế nào hihi
Anh ơi cho em hỏi, mình nên tập trung vào 1 FW để làm frontend, hay là nên học hết cả 3: angular, vue, react luôn ạ? E đang là sv cntt năm 3 ạ
hi Khánh, theo anh thì em chỉ nên tập trung 1 fw để học thôi nhé, a nghĩ em nên xuất phát từ reactjs đi nha Khánh 😉
PHẢI NÓI LÀ TUYỆT VỜI.
wohooo cảm ơn em nhiều nhé Shen ơi 😉
có 1 thắc mắc là, token lưu ở browser thì bảo mật sẽ như thế nào. User vẫn mò mẫm F12 và lấy được token và call API.
hi Vinh, user bình thường ko ai biết cách làm vậy nha Vinh 😉
Với lại đó là tài sản của user nè, nếu user lấy được token thì user cũng biết nó có tác dụng gì, nên nếu họ để lộ ra ngoài là lỗi của họ nhé Vinh 🙂
A hậu ơi! em đang gặp một vấn đề đó là khi em làm việc với Api và muốn thêm mới một user: thì em sẽ gọi thẳng đến Api createUser và await nó sau đó em gọi action để render lại toàn bộ data cho page đó. Vậy em muốn hỏi k bk vấn đề này của em có thể xử lí bằng cách khác tối ưu hơn được không ạ?? Mong a giải đáp thắc mắc ạ!
hi Tiến, việc em render lại cái list khi thêm user mới là đúng òi nè, không cần tối ưu gì thêm nha.
Với em lưu ý khi em render cái list, nó có key cho mỗi item, chỉ có item mới nó mới được thêm vào thôi, còn item cũ nó ko có render lại nên em yên tâm nha. 😉
Easy Frontend vâng ạ.em cảm ơn a nhiều nha❤️
bạn cho mình hỏi hiện tại cookie dùng cho những ứng dụng gì thế ?
hi Nam ơi, theo mình thấy thì mấy ứng dụng mới sau này thì hầu như ko có xài tới cookie-based auth nữa nè, may be là còn ở hệ thống cũ hoặc mấy cái CMS này nọ hoặc có những cái khác mà mình hk biết hihi
@@EasyFrontend thank bạn.
a ơi, v khi làm prj với firebase, lúc login băng email pass, thì firebase nó cũng save token lên localstrorage đúng k a
hi Trí, mình chưa thử với Firebase nên không rõ, nhưng chắc là vậy đó Trí ơi.
Trí mở localStorage lên check thử xem sao nhé 😉
Anh ơi, trong dự án sử dụng Angular + Nodejs, thì em thấy cả 2 thằng này đều tạo cookie được. Vậy tạo cookie bên client thì khác gì bên server ạ?
à phía server em có thể set cookies với HTTP_ONLY, như vậy sẽ ko truy cập bằng javascript được.
Còn phía client thì khi tạo cookies thì nó sẽ ko set http-only đc em nhen 😉
Em đang thắc mắc một số chỗ a gt giúp em với ạ
1. Theo e được biết thì Cookie được tạo bởi web server và quản lí bởi trình duyệt. Nhưng em thấy a lại ghi là quản lí bởi server.
2. Client side validatation có thay thế hoàn toàn được server side validation không ạ.
Em cảm ơn a
hi Long,
1. Ý anh để controlled by là được xử lý bởi server á Long, như ý em nói là đúng òi á.
2. Client side ko thay thế cho server side nha Long. Vì client thì có rất nhiều loại nè, có thể gọi từ web, mobile, terminal, bot, .... nên mình phải check trên server nha Long. Không bao giờ tin tưởng client nào hết nha. 😉
@@EasyFrontend kiến thức bổ ích quá. em cảm ơn anh ạ
Hay quá anh ơi, em cảm ơn a nhiều!!!!!
Yeahhh cảm ơn em nhiều nhé Vũ ơiiiiii 😍
Nếu dùng token authentication bên server thì sau khi logout, điều gì sẽ xảy ra nếu client gửi request lên và vẫn dùng token còn lưu bên phía client ạ?
à lúc đó em sẽ bị trả về lỗi 401 em nha 😉
Quá hay a ơi. Cảm ơn anh
hihi cảm ơn em nhiều nhé Quỳnh ơi 😍
Trong project thực tế khi anh đi làm thì a thường lưu token ở đâu ạ? =))
hi Lim ơi, mấy project ko strictly về tài chính, bảo mật thì lưu ở local storage là okie òi em ơi.
Còn mấy project liên quan tới tài chính thì xử lý ở cookies em nha 😉
@@EasyFrontend vâng ạ, thank you anh
@@EasyFrontend Dạ còn sessionStorage thì sử dụng cho project nào vậy ạ
Nhớ lại hồi trước mình cố gắng set cookie cho app ReactJS của mình set hoài không được rồi chuyển sang JWT xài mà không hiểu vì sao. Giờ mới biết cookie không cross domain được. Haha
haha ngon lành, cuối cùng cũng tìm ra được chân lý hehee 😍
Cho em hỏi nếu lưu token ở local storage thì có ảnh hưởng gì tới security không ạ ? Nếu bị lấy token và bị CSRF thì sao ạ ?
hi Thắng, em lưu ở local storage thì dĩ nhiên có risk nè, nếu bị attack trên domain của em thì chắc chắn lấy đc token.
Một số cân nhắc cho em:
- Mức độ security của dự án có cao hk? (thường liên quan tới tài chính thì ko nên lưu ở local storage, còn những web app đơn giản thì okie em nha)
- Giảm thời gian hiệu lực của token để khi bị mất cũng ko thiệt hại nhiều.
- Có cơ chế refresh token và block account khi cần thiết cho trường hợp có nghi vấn.
- Kẹp thêm các điều kiện để phát hiện truy cập lạ, ví dụ token này đi với trình duyệt này, nhưng lại đăng nhập ở nơi khác thì phải xác nhận thêm gì đó, ...
- ...
Em có thể trao đổi thêm với backend để tìm ra solution tương ứng em nha 😉
@@EasyFrontend Em cảm ơn anh ạ.
cho em hỏi vài câu
1. sessionId thường lưu vào database hay là ở ram ạ
2. token lưu ở cookie hay localStorage theo em tham khảo qua gg thì có vẻ lưu ở cookie bảo mật hơn vì httpOnly ko đc đc bằng js trên trình duyệt
anonystick.com/blog-developer/json-web-token-bao-mat-restful-api-voi-jwt-va-cookie-httponly-secure-201906223285306.jsx
. hóng :v
hi Mạnh, với 2 câu hỏi trên thì em có thể search google thêm nhen, có nhiều ý kiến lắm nè 😉
Còn theo anh thì:
1. SessionId thường sẽ được lưu vào db luôn nè, để trường hợp em có nhiều frontend khác nhau thì nó còn xử lý được, chứ trên RAM là chịu thua luôn, với nếu nhiều session thì e xử lý trên RAM hơi căng. Có thể e dùng thêm redis cache để xử lý vấn đề này cũng đc :)
2. Token thì mình nên lưu ở localstorage em nha, về bảo mật thì hầu hết các tình huống đều okie nè. Em lưu trong cookie thì nó lại quay về bài toán cookie ko cross domain đc, ko tương thích trên web với native app. Bản chất thì em muốn lưu đâu cũng đc, nhưng recommend vẫn là local storage nhé! 🙂
Easy Frontend em cảm ơn ạ
#1. Theo mình nó còn tùy vào nhu cầu app của bạn:
- 1.1 Có cần scale hay ko: nên lưu ở Redis or DB để những nơi khác có thể achieve đc.
- 1.2 Khi app bị shutdown thì chuyện ji xảy ra: User có còn đc duy trì đăng nhập khi app đc start -> Lại qua về 1.1
- 1.3 Thật ra không xài token-based auth mà dùng cookie thì vẫn có hướng đi đó là "FormsAuthentication": Lúc này cookie token gửi cho client là encoded string (machineKey, validation type (SHA1) và decryption (AES) nằm ở web config).
#2. Như anh Hậu chia sẻ thì rõ ràng dù là cookie hay token lưu ở bất kì đâu, việc bảo quản nó là việc nên làm của user. Bên .net web app có khái niệm gọi là "@Html.AntiForgeryToken()" để tránh tình trạng Cross-site request forgery (CSRF).
~ Phong Nguyễn ~
Anh ơi em có thắc mắc mình lưu token như v lỡ như bị hacker chôm thì sao anh, có cách nào bảo vệ ko ạ.
hi em ơi, cái này thì mình chỉ có cách hạn chế chứ hk có cách nào chặn hoàn toàn nè.
Cái token em nên để thời gian hiệu lực khoảng 2 giờ thôi nè, để lỡ khi có mất thì nó cũng hk còn hiệu lực bao lâu để sử dụng, hoặc nhiều khi nó đã expired mất tiu rồi hehee Còn em mà dùng token ko bao giờ expired thì hơi nguy hiểm. Còn việc chặn hacker thì chắc ko đc đâu em, nếu được thì mấy hệ thống lớn, bự nó ko bị tấn công đâu nè 😉
@@EasyFrontend Vâng em cám ơn
cảm ơn anh
toẹt vời a Hậu ơi :D
hihi cảm ơn em nhiều nhé Tùng 😉
❤ cảm ơn anh
tạo ra token ở backend thì nó đc lưu ở đâu vậy a?
FREE SOFTWARE hi em, token tạo ra rồi trả về bên client nhé em, server ko cần lưu nè, khi nào client gửi token đó lên thì server sẽ validate cái token xem hợp kệ hay ko thôi nhen 😉
@@EasyFrontend Ad có thể nói rõ việc server validate token đó lại không ạ. Nếu client edit token thì server sao biết dc nhỉ trong trường hợp nó ko lưu lại
@@gauphepha493 server sẽ có secrect key kết hợp (lúc tạo ra) token và dùng để compare khi client gửi lên nhe
anh Hậu ơi ra video nhanh lên !
hahaa max-speed rồi em ơi, hôm giờ sml quá 😅
A hậu làm demo login auth đi anh
Yeah chuẩn bị làm rồi nha Hiếu ơi, giải thích một vài khái niệm trước, xong anh mới code nhen hehe
Easy Frontend hóng lắm video của anh
Bài này ông dạy sai r, 2p30s đầu tiên chưa thấy đúng chỗ nào luôn
hi Tiến, video này mình làm 2 năm trc òi, hk biết mình sai chỗ nào, nhờ bạn nói rõ thêm để mình học hỏi nhé 🙏
chấm mút, watch later :v
Trình bày ko dễ hiểu. Nói toàn từ chuyên môn ko dành cho ng mới tiếp cận