4 Cơ chế xác
thực:
1. Xác thực
với Session và Cookie
2. Xác thực
với Token
3. Xác thực OAUTH 2.0
4. Xác thực SINGLE
SIGN-ON (SSO)
Cùng tìm hiểu về 4 cơ chế xác thực này qua
loạt bài tổng hợp dưới đây nhé:
I. PHÂN BIỆT
SỰ KHÁC NHAU GIỮA AUTHENTICATION VÀ AUTHORIZATION
Authentication
(xác thực) có nghĩa là xác nhận danh tính của riêng bạn, trong khi
authorization (ủy quyền) có nghĩa là cấp quyền truy cập vào hệ thống. Nói một
cách đơn giản, authentication là quá trình xác minh bạn là ai, trong khi
authorization là quá trình xác minh những gì bạn có quyền truy cập.
1. Authentication
Authentication là về việc xác thực thông tin đăng nhập của bạn
như Tên người dùng / ID người dùng và mật khẩu để xác minh danh tính của bạn.
Trong các public và private network, hệ thống xác thực danh tính người dùng
thông qua mật khẩu đăng nhập. Authentication thường được thực hiện bởi tên
người dùng và mật khẩu, và đôi khi kết hợp với các yếu tố xác thực, trong đó đề
cập đến các cách khác nhau để được xác thực.
Các Authentication factor xác định các yếu tố khác nhau mà hệ
thống sử dụng để xác minh một danh tính trước khi cấp cho anh ta quyền truy cập
vào bất cứ điều gì từ việc truy cập file đến yêu cầu giao dịch ngân hàng. Một
danh tính người dùng có thể được xác định bởi những gì anh ta biết, những gì
anh ta có. Khi nói đến bảo mật, ít nhất hai hoặc cả ba yếu tố xác thực phải
được xác minh để cấp cho ai đó quyền truy cập vào hệ thống.
Dựa trên cấp độ bảo mật, authentication factor có thể thay đổi
theo một trong các cách sau:
Single-Factor Authentication – Nó là phương thức xác thực đơn giản nhất thường dựa vào
mật khẩu đơn giản để cấp cho người dùng quyền truy cập vào một hệ thống cụ thể
là một website hoặc network. Người này có thể yêu cầu quyền truy cập vào hệ
thống chỉ bằng một trong các thông tin đăng nhập để xác minh danh tính của
mình. Ví dụ phổ biến nhất về xác thực một yếu tố sẽ là thông tin đăng nhập chỉ
yêu cầu mật khẩu đối với tên người dùng hoặc địa chỉ email.
Two-Factor Authentication – Như tên của nó, nó có một quy trình xác minh gồm hai
bước, không chỉ yêu cầu tên người dùng và mật khẩu, mà còn một thứ mà chỉ người
dùng biết, để đảm bảo mức độ bảo mật bổ sung, chẳng hạn như tin nhắn về số điện
thoại, mail, hoặc cần xác thực từ một thiết bị khác đã đăng nhập, chỉ người
dùng mới biết. Sử dụng tên người dùng và mật khẩu cùng với một thông tin bí mật
bổ sung khiến cho những kẻ lừa đảo hầu như không thể đánh cắp dữ liệu có giá
trị.
Multi-Factor Authentication – Nó có một phương thức xác thực tiên tiến nhất sử dụng
hai hoặc nhiều mức bảo mật từ các loại xác thực độc lập để cấp quyền truy cập
cho người dùng vào hệ thống. Tất cả các yếu tố phải độc lập với nhau để loại bỏ
bất kỳ lỗ hổng nào trong hệ thống. Các tổ chức tài chính, ngân hàng và các cơ
quan thực thi pháp luật sử dụng xác thực nhiều yếu tố để bảo vệ dữ liệu và ứng
dụng của họ khỏi các mối đe dọa tiềm ẩn.
Ví dụ: khi bạn nhập thẻ ATM vào máy ATM, máy sẽ yêu cầu bạn nhập
mã pin. Sau khi bạn nhập mã pin chính xác, ngân hàng sẽ xác nhận danh tính của
bạn rằng thẻ thực sự thuộc về bạn và bạn là chủ sở hữu hợp pháp của thẻ. Bằng
cách xác nhận mã pin thẻ ATM của bạn, ngân hàng thực sự xác minh được danh tính
của bạn, được gọi là authentication. Nó chỉ đơn thuần xác định bạn là ai, không
có gì khác.
2. Authorization
Mặt khác, Authorization xảy ra sau khi
hệ thống của bạn được authentication (xác thực) thành công, cuối cùng cho phép
bạn toàn quyền truy cập các tài nguyên như thông tin, file, cơ sở dữ liệu, quỹ,
địa điểm, hầu hết mọi thứ. Nói một cách đơn giản, authorization xác định khả
năng của bạn để truy cập hệ thống và ở mức độ nào. Khi danh tính của bạn được
hệ thống xác minh sau khi xác thực thành công, bạn sẽ được phép truy cập tài
nguyên của hệ thống.
Authorization là quá trình để xác định
xem người dùng được xác thực có quyền truy cập vào các tài nguyên cụ thể hay
không. Nó xác minh quyền của bạn để cấp cho bạn quyền truy cập vào các tài
nguyên như thông tin, cơ sở dữ liệu, file, v.v. Authorization thường được đưa
ra sau khi xác thực xác nhận các đặc quyền của bạn để thực hiện. Nói một cách
đơn giản hơn, nó giống như cho phép ai đó chính thức làm điều gì đó hoặc bất cứ
điều gì.
Ví dụ, quy trình xác minh và xác nhận ID
nhân viên và mật khẩu trong một tổ chức được gọi là authentication, nhưng xác
định nhân viên nào có quyền truy cập vào tầng nào được gọi là authorization.
Hãy nói với bạn rằng bạn đang đi du lịch và bạn sẽ lên một chuyến bay. Khi bạn
xuất trình vé và một số giấy tờ tùy thân trước khi nhận phòng, bạn sẽ nhận được
thẻ lên máy bay xác nhận rằng cơ quan sân bay đã xác thực danh tính của bạn.
Nhưng đó không phải là nó. Một tiếp viên hàng không phải ủy quyền cho bạn lên
chuyến bay mà bạn được cho là đang bay, cho phép bạn truy cập vào bên trong máy
bay và các tài nguyên của nó.
Truy cập vào một hệ thống được bảo vệ
bởi cả authentication và authorization. Mọi nỗ lực truy cập hệ thống có thể
được xác thực bằng cách nhập thông tin xác thực, nhưng chỉ có thể được chấp
nhận sau khi ủy quyền thành công. Nếu nỗ lực được xác thực nhưng không được
phép, hệ thống sẽ từ chối quyền truy cập vào hệ thống.
|
Authentication |
Authorization |
|
Authentication xác nhận
danh tính của bạn để cấp quyền truy cập vào hệ thống. |
Authorization xác định
xem bạn có được phép truy cập tài nguyên không. |
|
Đây là quá trình xác
nhận thông tin đăng nhập để có quyền truy cập của người dùng. |
Đó là quá trình xác
minh xem có cho phép truy cập hay không. |
|
Nó quyết định liệu
người dùng có phải là những gì anh ta tuyên bố hay không. |
Nó xác định những gì
người dùng có thể và không thể truy cập. |
|
Authentication thường
yêu cầu tên người dùng và mật khẩu. |
Các yếu tố xác thực cần
thiết để authorization có thể khác nhau, tùy thuộc vào mức độ bảo mật. |
|
Authentication là bước
đầu tiên của authorization vì vậy luôn luôn đến trước. |
Authorization được thực
hiện sau khi authentication thành công. |
|
Ví dụ, sinh viên của
một trường đại học cụ thể được yêu cầu tự xác thực trước khi truy cập vào
liên kết sinh viên của trang web chính thức của trường đại học. Điều này được
gọi là authentication. |
Ví dụ, authorization
xác định chính xác thông tin nào sinh viên được phép truy cập trên trang web
của trường đại học sau khi authentication thành công. |
II. 02 CƠ CHẾ XÁC THỰC:
SESSION, TOKEN
Giới thiệu nhanh về HTTP
HTTP là giao thức
cơ bản được World Wide Web sử dụng và giao thức này xác định cách thức thông
báo được định dạng và truyền đi cũng như các hành động mà server và trình duyệt
Web phải thực hiện để đáp ứng các lệnh khác nhau. HTTP như là một cầu nối giữa
client và server.
Có
rất nhiều khía cạnh khi nói về HTTP, tuy nhiên trong bài viết này chúng ta chỉ
đề cập tới những tính chất liên quan nhất đến chủ đề chính của bài viết hôm nay
đó là stateless. Stateless nghĩa là giữa hai
yêu cầu HTTP bất kì không có bất cứ liên kết gì với nhau cả, mỗi request về
server là độc lập. Ví dụ dễ hiểu hơn, ví dụ bạn đăng nhập Facebook với tài
khoản của bạn, và ngay sau đó bạn điều hướng tới trang cài đặt hoặc trang cá
nhân thì bạn sẽ bị yêu cầu đăng nhập lại vì server không biết rằng bạn là người
vừa đăng nhập. Tuy nhiên, với session và token chúng ta có thể nói cho server
biết tôi là người vừa đăng nhập vào tài khoản đó và hãy cấp quyền cho tôi truy
cập vào trang đó.
Flow làm việc của
cookie vs token nhìn vào hình vẽ bên trên thì flow 2 thằng sẽ gần giống nhau. Ở
đây mình sẽ có 2 phần đó là browser và server.
browser hay còn
gọi là trình duyệt, là các ứng dụng mà bạn dùng để lướt web như chorme, coccoc…
đóng vai trò là phía client. Đầu tiên khi mà bạn login vào 1 hệ thống, thì phía
trình duyệt của bạn sẽ gửi lên server thông tin username và password bạn vừa
nhập ở phía trình duyệt của bạn vào
Ví dụ khi bạn
login vào Facebook, thì bạn cần nhập thông tin username và password của bạn vào
ô đăng nhập, sau đó khi bạn ấn button đăng nhập. Thì phía client sẽ gửi thông
tin đó lên phía server để tiếp nhận và xử lý.
về phần phía
server sau khi tiếp nhận được thông tin username và password, thì việc tiếp
theo là phải check thông tin trong database để xem username và password có tồn
tại trong hệ thống hay không. Sau đó trả lại kết quả cho phía client. Trong
trường hợp mà thông tin username và password hợp lệ, thì phía server sẽ trả về
cho client một thông tin nào đó (có thể là 1 đoạn token, hay 1 giá trị nào đó).
Phía client sẽ lưu cái thông tin trả về đó lại và khi phía client muốn thực
hiện 1 request đến server, thì client sẽ phải gửi kèm cái thông tin vừa lưu đó
cùng với request lên server.
Ở đây việc vào nhà cũng
như việc bạn truy cập vào bên trong hệ thống, chỉ có những người của hệ thống
mới có và nắm giữ được thông tin từ phía server trả về. Từ thông tin đó thì hệ
thống mới biết và nhận dạng được là user đó có đúng là của hệ thống mình không.
Lúc đó mới cấp quyền cho truy cập hệ thống. Thì sau khi login thành công và
nhận được thông tin từ phía server trả về, mỗi lần phía client request thì phải
đính kèm thông tin đó theo. Phía server sẽ có nhiệm vụ là validate cái thông
tin đính kèm đó. Nếu hợp lệ thì sẽ trả lại response cho phía client, còn trường
hợp không hợp lệ thì sẽ không trả về dữ liệu. Với cái flow này thì cả 2 sẽ
tương tự như nhau, nhưng cách thực hiện và triển khai sẽ khác nhau.
1.
Session là gì? Cookie là gì?
Session là gì?
Khái niệm session là gì không quá xa lạ
với các fresher, Session là một phiên làm việc là
một khái niệm phổ biến được dùng trong lập trình web có kết nối với database.
Đặc biệt các chức năng như đăng nhập, đăng xuất người dùng sẽ khó có thể thực
hiện được nếu không sử dụng session. (Cookie là nơi lưu trên trình duyệt của
người dùng)
Xác thực với Session và Cookies
(cookie là nơi lưu session ID)
Một session bắt
đầu khi client gửi request đến server, nó tồn tại xuyên suốt từ trang này đến
trang khác trong ứng dụng web và chỉ kết thúc khi hết thời gian timeout hoặc
khi bạn đóng ứng dụng. Giá trị của session sẽ được lưu trong một file trên
server.
Ví dụ khi bạn đăng nhập vào một trang
web và đăng nhập với tài khoản đã đăng ký trước đó. Server sau khi xác thực
được thông tin bạn cung cấp là đúng thì nó sẽ sinh ra một tập tin chứa dữ
liệu cần lưu trữ của người dùng.
Cách đơn giản nhất để nói
cho server biết rằng chúng ta là người vừa đăng nhập là username và mật khẩu của
người dùng sẽ được lưu trữ tại cookie trên máy client và request gửi lên tiếp
theo sẽ gửi kèm theo username và mật khẩu, đây là cách thông thường mà chắc ai
cũng nghĩ tới tuy nhiên việc lưu trữ username và mật khẩu tại máy client là không
an toàn về mọi mặt. Vậy lưu trữ ở client không an toàn chúng ta sẽ chuyển sang
lưu trữ các thông tin này trên server.
Xác thực bằng session là
cách mà thông tin về trạng thái của người dùng sẽ được lưu trữ vào bộ nhớ của
server. Khi sử dụng hệ thống xác thực dựa trên session, server sẽ tạo và lưu trữ
dữ liệu phiên trong bộ nhớ của nó khi người dùng đăng nhập và sau đó lưu
session ID trong cookie trên trình duyệt của người dùng. Session ID sẽ được gửi
lên cùng trong các request tiếp theo từ máy client tới server, và server sẽ so
sánh nó với dữ liệu được lưu trữ trong bộ nhớ của server.
Với cơ chế này thì sau
khi đăng nhập, server sẽ tạo ra session cho user và lưu vào đâu đó (có thể là
file, memory, database,…). Sau đó một session ID sẽ được lưu vào trong cookies
của trình duyệt. Trong khi user truy cập vào website thì session ID đó sẽ được
trình duyệt lấy ra và gửi kèm theo trong request. Nhờ vậy mà server có thể tham
chiếu đến session đã lưu trên server để biết user này đã đăng nhập hay chưa.
Sau khi user log-out (đăng xuất) thì session sẽ bị xóa đi.
Thực tế, khi
bạn gửi thông tin username và password lên server thì server (Đối với cookie
base) sẽ tạo ra 1 session, hay còn gọi là 1 phiên làm việc giữa client và
server. Phía server sẽ lưu thông tin session đó vào trong database và sẽ set
cookie ở phía client với thông tin session id chính là cái id vừa mới tạo ra.
Điều này để giúp nhận ra được đây là phiên làm việc giữa client này và server.
1 server sẽ làm việc với rất nhiều client, mỗi client sẽ nắm giữ session id
khác nhau. Khi mà phía client đã có cookie lưu lại session rồi thì với mỗi lần
thực hiện request, cookie sẽ gửi lên bao gồm cả thông tin session id đến phía
server. Phía server sẽ lấy ra thông tin session id đó và đem so sánh với
database để xem session đó có hợp lệ hay không. Và để kiểm tra xem session id đó
thuộc user nào, user đấy có thông tin gì, có những quyền nào đối với hệ thống,
được phép truy cập những tài nguyên nào. Từ đó sẽ trả ra response, còn đối với
session id k hợp lệ, thì sẽ k trả ra dữ liệu.
Điều mình nhận
thấy ngay ở đây là gì, mỗi khi có client truy cập đến server, phía server sẽ
phải tạo ra một session và phải lưu trữ nó lại trong database để kiểm tra và xử
lý nó. Và mỗi 1 request, server sẽ lại phải lấy session id mà client gửi lên để
query db xem session đó có hợp lệ hay không. Với số lượng client nhiều thì phía
server sẽ phải lưu trữ và xử lý rất nhiều. Điều này làm giảm performance của hệ
thống và tăng số lượng data mà hệ thống phải lưu trữ. Vì vậy mà cách
authentication bằng Cookie Base ngày này không còn được sử dụng nhiều nữa. Thay
vào đó là sẽ được thay thế bởi Token Base. Thì Token Base hoạt động như thế
nào, và nó khắc phục nhược điểm của Cookie Base ra sao thì mình sẽ cùng đi tìm
hiểu tiếp về Token Base.
2. Xác thực với token
Xác thực với token là một
phương pháp xác thực mà trạng thái của user sẽ được lưu trữ tại máy client và
dĩ nhiên là không phải lưu trữ dạng thô như cách mà chúng ta đề cập ở bên trên.
Hiện nay thì xác thực với token là lựa chọn ưa thích cho RESTful API. Trong xác
thực với token, dữ liệu người dùng được mã hóa thành JWT (Json Web Token) với một
secret và được gửi lại cho client. JWT sau đó được lưu trữ ở phía máy client và
được gửi kèm theo trong các request tiếp theo trong header, server xác thực JWT
được gửi lên trước khi gửi phản hồi lại cho máy client.
Thực tế, việc authentication bằng Token Base thì bạn vẫn
sẽ phải gửi lên username và password. Sau khi check rằng username và password hợp
lệ, thì server sẽ tạo ra 1 token. Ở đây thì mình khuyến khích dùng JWT (Json
Web Token, mình sẽ làm 1 bài khác nói rõ hơn về JWT). Hiểu đơn giản là server sẽ
tạo ra 1 token, và token sẽ chứa các thông tin liên quan đến việc dùng để
verify ví dụ như role của user… Thì phía trình duyệt sau khi nhận dc token này,
sẽ lưu vào local storage. Và mỗi khi thực hiện 1 request, trình duyệt sẽ đính
kèm cái token này vào cái header authorization và gửi ngược lại lên server. Lúc
này nhiệm vụ của server là đi validate cái token này, xem token có hợp lệ hay
không. Và nếu token bị sửa đổi ở phía client thì phía server sẽ phát hiện ra và
token đó sẽ không còn hợp lệ. Cơ chế ra sao thì ở bài sau mình sẽ nói rõ. Và ok
khi mà nó kiểm tra được rằng token này đã hợp lệ, thì lúc này nó sẽ coi đây là
1 request hợp lệ và sẽ trả ra dữ liệu. Ở đây khác với Cookie Base , thằng Token
Base sẽ không phải lưu trữ, quản lý các token. Không phải query xuống database
để kiểm tra token. Việc này giúp cho việc thực hiện request sẽ nhanh và đơn giản
hơn nhiều. Giảm thiểu công việc khi phát triển hệ thống. Và khi logout, thì bạn
phải gửi 1 yêu cầu để server nó xóa cái token đó đi. Điều này nhằm đảm bảo tính
bảo mật, nếu không thì token vẫn còn hợp lệ.
Khi nhắc đến cơ
chế xác thực đăng nhập bằng Token (Token-Based Authentication) thì đa phần
người ta thường nhắc đến JWT. Trước đây thì các trang web chỉ sử dụng cơ chế
Session và Cookies tuy vậy hiện nay cơ chế sử dụng Token vô cùng phổ biến và
dần trở thành một tiêu chuẩn cho việc xác thực đăng nhập.
– Cơ chế của JWT
là như thế nào? Khi user đăng nhập thì server sẽ tạo ra một đoạn token được mã
hóa và gửi lại nó cho client. Khi nhận được token này thì client sẽ lưu trữ vào
bộ nhớ (thường sẽ là local storage). Sau đó mỗi khi client request lên server
thì sẽ gửi kèm theo token. Từ token này server sẽ biết được user này là ai.
Ưu và nhược điểm của xác
thực bằng token so với session
Ưu điểm
- Xác thực bằng token là có khả năng mở rộng và hiệu quả hơn: vì sessions lưu trữ
trên server, khả năng mở rộng là một vấn đề khi có một lượng lớn người dùng sử
dụng hệ thống cùng 1 lúc còn với token là không thành vấn đề khi chúng được lưu
trữ tại client. Hơn nữa, server chỉ cần tạo và xác minh token cùng với thông
tin, có nghĩa là có thể duy trì nhiều người dùng hơn trên một trang web hoặc
ứng dụng cùng một lúc mà không gặp bất kỳ rắc rối nào.
- Xác thực bằng token linh hoạt và có hiệu suất cao: token có thể được
sử dụng trên nhiều máy chủ và chúng có thể cung cấp xác thực cho các trang web
và ứng dụng khác nhau cùng một lúc. Điều này giúp khuyến khích nhiều cơ hội hợp
tác hơn giữa các doanh nghiệp và nền tảng để có trải nghiệm hoàn hảo.
- Xác thực bằng token là bảo mật
Hạn chế
Secret key bị mất: token chỉ dựa vào một khóa duy nhất vì vậy
nếu vì bất cứ lý do gì mà khóa này bị mất hoặc bị lộ thì sẽ gây đến các hậu quả
nghiêm trọng.
Token có kích thước lớn hơn nhiều so với Session ID được lưu trữ
trong cookie vì token chứa nhiều thông tin của người dùng hơn
Thời gian sử dụng của token thường ngắn hơn so với session
Ngoài ra có nhiều ý kiến cho rằng token là kém bảo mật hơn so
với session
Vậy nên sử dụng session
hay token?
Mặc dù token đang có chút lợi thế tuy
nhiên chúng ta không thể khẳng định ngay là phương pháp nào được ưu tiên để xác
thực. Cả hai phương pháp có thể được sử dụng để thay thế cho nhau hoặc kết hợp
cả hai trong một hệ thống, điều này còn tùy thuộc vào doanh nghiệp, nhóm phát
triển và trường hợp sử dụng.
III.
SỰ KHÁC NHAU VÀ CÁCH SỬ DỤNG LOCAL STORAGE, SESSION STORAGE VÀ COOKIE
Bạn bị lẫn lộn giữa session
storage, local storage và cookies? Bài viết
dưới đây sẽ giúp bạn hiểu rõ được sự khác nhau giữa 3 cách lưu trữ này. Các
kiểu không gian lưu trữ khác nhau có sẵn cho các dữ liệu có thể trên máy chủ
hoặc máy khách, cho phép chúng ta chọn lựa theo nhu cầu.
1. Local storage
Giới thiệu:
Khả năng lưu trữ vô thời hạn: Có nghĩa là chỉ bị xóa bằng
JavaScript, hoặc xóa bộ nhớ trình duyệt, hoặc xóa bằng localStorage API.
Lưu trữ được 5MB: Local Storage cho phép bạn lưu trữ thông tin
tương đối lớn lên đến 5MB, lưu được lượng thông tin lớn nhất trong 3 loại.
Không gửi thông tin lên server như Cookie nên bảo mật tốt hơn.
2. Session Storage
Giới thiệu:
Lưu trên Client: Cũng giống như localStorage thì sessionStorage
cũng dùng để lưu trữ dữ liệu trên trình duyệt của khách truy cập (client).
Mất dữ liệu khi đóng tab: Dữ liệu của sessionStorage sẽ mất khi
bạn đóng trình duyệt.
Dữ liệu không được gửi lên Server
Thông tin lưu trữ nhiều hơn cookie (ít nhất 5MB)
3. Cookie
Giới thiệu:
Thông tin được gửi lên server: Cookie sẽ được truyền từ server
tới browser và được lưu trữ trên máy tính của bạn khi bạn truy cập vào ứng
dụng, mỗi khi người dùng tải ứng dụng, trình duyệt sẽ gửi cookie để thông báo
cho ứng dụng về hoạt động trước đó của bạn. Vì vậy đừng bao giờ lưu trữ những
thông tin quan trọng, yêu cầu tính bảo mật cao vào cookie vì nó hoàn toàn có
thể bị sửa đổi và đánh cắp, thấp chí có thể lợi dụng điều này để tấn công
website của bạn.
Cookie chủ yếu là để đọc phía máy chủ (cũng có thể được đọc ở
phía máy khách), localStorage và sessionStorage chỉ có thể được đọc ở phía máy
khách.
Có thời gian sống: Mỗi cookie thường có khoảng thời gian timeout
nhất định do lập trình viên xác định trước.
Lưu
trữ: cho phép lưu trữ tối đa 4KB và vài chục cookie cho một domain.
4. Thông tin thêm
Vì localStorage và sessionStorage được lưu trữ trên trình duyệt
của người dùng, nên các bạn cần phải xem xét nội dung lưu trữ có liên quan đến
vấn đề bảo mật hay không.
Và cũng chính vì localStorage và sessionStorage được lưu trữ
trên trình duyệt nên việc sử dụng nó sẽ không ảnh hưởng đến hiệu xuất của trang
web nhưng nó sẽ làm nặng trình duyệt của người dùng (không đáng kể).
Về phạm vi: sessionStorage: giới hạn trong một cửa
sổ hoăc thẻ của trình duyệt. Một trang web được mở trong hai thẻ của cùng một
trình duyệt cũng không thể truy xuất dữ liệu lẫn nhau. Như vậy, khi bạn đóng
trang web thì dữ liệu lưu trong sessionStorage hiện tại cũng bị xóa. Còn localStorage:
có thể truy xuất lẫn nhau giữa các cửa sổ trình duyệt. Dữ liệu sẽ được lưu trữ
không giới hạn thời gian.
Nguồn tham khảo:
https://duthanhduoc.com/blog/p1-giai-ngo-authentication-basic-authentication
https://duthanhduoc.com/blog/p2-giai-ngo-authentication-session
https://duthanhduoc.com/blog/p3-giai-ngo-authentication-jwt
https://duthanhduoc.com/blog/p4-luu-jwt-token-o-localstorage-hay-cookie
https://duthanhduoc.com/blog/p5-giai-ngo-authentication-OAuth2
Tham khảo thêm:
0 comments:
Đăng nhận xét