Social login cũng là một dạng của single sign-on như Facebook, Google

Ưu và nhược điểm của SSO

Một vài ưu điểm có thể kể đến của Single Sign-On là:

• Giảm số lượng tên đăng nhập (username) và mật khẩu (password) mà người dùng cần phải ghi nhớ.
• Giảm số lần phải nhập thông tin tên đăng nhập và mật khẩu.
• Những rủi ro về việc lộ thông tin người dùng khi đăng nhập nhiều lần cũng được tiết chế lại.

Tất nhiên không một công cụ nào có là hoàn hảo, ngoài những lợi ích SSO cũng có một vài hạn chế không thể chối bỏ như:

• Phát sinh thêm các chi phí phát triển khi thông qua server bên thứ ba.
• Phải phụ thuộc vào bên cung cấp dịch vụ SSO.

Cơ chế hoạt động của SSO là gì

Hệ thống nhận dạng liên kết là nơi tập trung là liên kết những thông tin của người dùng lại với nhau. Có 4 tiêu chí để cấu thành nên hệ thống nhận dạng liên kết.

• Xác thực (Authentication): đây là bước để xác minh danh tính của người sử dụng thông qua việc kiểm tra các thông tin đăng nhập.
• Phân quyền (Authorization): sau khi đã xác thực và lấy danh tính xong, SSO sẽ dựa vào đó để kiểm tra các quyền truy cập của người sử dụng.
• Trao đổi thông tin người dùng (User attributes exchange): những thông tin người dùng như họ, tên, quê quán,... sẽ dễ bị trùng lặp. Chính vì vậy các hệ thống con cần những thông tin này và phải lưu trữ chúng. Những thông tin này sau khi được thu thập sẽ được tổng hợp lại và trao đổi với hệ thống con.
• Quản lý người dùng (User management): quản trị viên của trang web có quyền quản lý người dùng thông qua các hoạt động trên hệ thống con như thêm mới, chỉnh sửa và xóa.

Single Sign-On là một phần của hệ thống nhận dạng liên kết, do đó nó  có mối liên quan chặt chẽ với việc xác nhận thông tin của người sử dụng. SSO sẽ định danh người dùng và chia sẻ những thông tin đã được định danh với các hệ thống con.

Bạn có thắc mắc Single sign-on hoạt động như thế nào không? Khi bạn đăng nhập vào trang web X thì domain của X sẽ tự động lưu trữ những thông tin đăng nhập này vào cookie. Tiếp đó, để bạn có thể tiếp tục đăng nhập khi truy cập vào trang web Y thì domain của Y sẽ phải đọc được cookie đã được lưu trữ của trang X. Xét về mặt lý thuyết thì điều này gần như là không thể xảy ra vì domain của các trình duyệt hiện nay chỉ cho phép truy cập cookie do chính nó tạo ra mà thôi.

SSO sẽ đảm nhận nhiệm vụ chia sẻ thông tin cookie cho các domain của những trang web lại với nhau. SSO gồm nhiều giao thức với các cơ chế chia sẻ khác nhau nhưng cuối cùng tất cả sẽ đều tạo ra một domain trung tâm. Từ domain trung tâm này, thông tin về cookie của các trang web sẽ được chia sẻ đến những domain con.

Để có thể dễ hình dung, các bạn có thể tham khảo ví dụ sau. Chẳng hạn, domain trung tâm tạo ra một “json web token (jwt)” và mã hóa nó. Khi bạn truy cập vào những trang web thuộc domain con thì sẽ được điều hướng đến domain trung tâm này. Token sẽ được truy xuất và trả lại sau đó lưu ở trình duyệt. Tiếp đến, nếu bạn muốn tiếp tục truy cập vào những domain con khác thì cũng tương tự, tất cả sẽ được điều hướng đến domain trung tâm, tuy nhiên do lần này đã có token từ trước nên việc đăng nhập lại là không cần thiết nữa

Vậy SSO hoạt động như thế nào?

Khi bạn đăng nhập vào trang web A thì domain của A sẽ tự động lưu ngay thông tin đăng nhập của bạn vào cookie.

Để có thể dễ hình dung, mình sẽ lấy cho các bạn một ví dụ.

Ví dụ, domain trung tâm tạo ra một json web token (jwt) và mã hóa nó. Khi bạn truy cập vào trang web mang domain con thì sẽ được điều hướng đến domain trung tâm này token sẽ được trả lại và lưu ở trình duyệt.

Sau đó, nếu bạn tiếp tục truy cập vào những domain con khác thì tương tự, cũng sẽ được điều hướng đến domain trung tâm, nhưng do lần này đã có token nên việc đăng nhập lại là không cần thiết nữa.

Social login

Social login cũng là một dạng của Single Sign-On. Chắc hẳn bạn không còn xa lạ với những trang web có các phương thức đăng nhập khác nhau thông qua các hệ thống mạng xã hội như Facebook, Google, Twitter, Linkedin,... Người dùng có thể sử dụng các thông tin đã được đăng nhập sẵn trên các mạng xã hội này để đăng ký, đăng nhập vào server bên thứ ba mà không cần phải tạo tài khoản. Và tất nhiên, domain trung tâm khi này sẽ là domain của các mạng xã hội.Các hệ thống phân tán (Decentralized System) ngày càng trở nên phổ biến và vấn đề xác thực thông tin là một khía cạnh quan trọng của tất cả chúng.

SSO đã giúp giải quyết một vấn đề lớn là làm thế nào để quản lý được số lượng người dùng đang ngày càng gia tăng trên toàn bộ hệ thống gồm nhiều ứng dụng và dịch vụ. Các framework như OpenID Connect và các dịch vụ như Auth0 làm cho việc tích hợp SSO vào các ứng dụng mới hoặc đã có của người dùng trở nên dễ dàng hơn nhiều. Nếu bạn đang có nhu cầu triển khai xác thực trên một ứng dụng hay dịch vụ nào đó hãy xem xét việc tích hợp SSO nhé.

Xem thử case này

Một user khi đăng nhập vào hệ thống A thì domain của A sẽ lưu thông tin định danh vào cookie, để user này cũng là đã đăng nhập khi truy cập vào hệ thống B thì domain B sẽ phải đọc được cookie của A tạo ra, nhưng điều này là không thể. Với các trình duyệt hiện nay, domain chỉ có thể truy cập cookie do chính nó tạo ra.

Vì vậy, single sign-on sẽ phải chia sẻ thông tin cookie giữa các domain với nhau. Mỗi giao thức single sign-on sẽ có cơ chế chia sẻ khác nhau, nhưng điểm chung đều là tạo ra một domain trung tâm (central domain). Qua domain này, thông tin về cookie sẽ được chia sẻ đến các domain con. Ví dụ, central domain có thể tạo ra một json web token (jwt) và mã hóa nó. Khi ngươi dùng truy cập vào domain con thì sẽ được điều hướng đến domain trung tâm này, và token sẽ được trả lại và lưu ở phía trình duyệt. Sau đó, nếu người dùng tiếp tục truy cập vào domain con khác thì tương tự, cũng sẽ được điều hướng đến domain trung tâm, nhưng do lần này đã có token nên sẽ được định danh và việc đăng nhập lại là không cần thiết nữa.

Đọc xong cũng thấy khá logic, nhưng khi kéo xuống các câu hỏi bên dưới, thì mình thấy có một câu được rất nhiều vote up như thế này:

What is browser cookie storage and how it is accessible to by all three apps? I am supposing, the token should be stored by auth server and accessible to auth server, and after authentication browser is sending auth token with each request, and authenticated at auth server side, so why other apps are accessing browser cookie storage?

Since it's a domain specific, private storage, shouldn't the representation of browser storage not have all three domains pointing to it? They don't share the same browser cookie storage. They only share the same information, but in different stores. Is that not correct? I realize that makes the visual a little more disparate, but the principle is an important one to understand and changes the flow slightly.

Hiểu là: brower lưu cookie kiểu gì vậy? Tôi đang hiểu là mỗi domain sẽ có 1 storage riêng trong local storage tổng để lưu cookie. Khi access đến domain1 và được redirect đến central domain xong thì sẽ có cookie lưu trong storage của domain1 và central, sau đó, với domain2 thì làm thế nào để lấy được cookie của central Mình nghĩ là câu này cũng sẽ có nhiều người thắc mắc (vì có nhiều vote up mà) nên có một số ý hiểu mình muốn chia sẻ đó là:

• Local storage không chia thành nhiều storage con, mà chỉ có duy nhất một local storage mà thôi, tất cả cookie đều sẽ được lưu ở một chỗ, dạng key (là domain) và value. Chỉ là, các domain sẽ chỉ có quyền access đối với data mà nó tạo ra thôi.

• Không có chuyện các domain sử dụng cookie của nhau. Các domain sẽ tự request đến center domain và tự lưu cookie được trả ra, sau đấy, với mỗi request thì các domain sẽ tự dùng cookie mà mình có

• Phần lớn các service SSO hiện nay (ví dụ ở đây là Auth0) có 2 cách để xử lí ở vấn đề này:

  • Do tính chất của cookie, là các domain và subdomain có thể truy cập qua lại, nên central domain sẽ là dạng subdomain đối với một trong số các domain con. Ví dụ: domain con là abc.com thì auth0 sẽ tạo ra một central domain là auth0.abc.com. khi đấy, user nếu đã login ở abc.com thì sẽ có cookie lưu ở local storage mà cả abc.com và auth0.abc.com đều truy cập được. Khi đấy, nếu user login ở edf.com thì sẽ được redirect về central domain là auth0.abc.com, và sẽ có cookie, và lúc đấy user sẽ được xác thực
  • Sử dụng cơ chế Cross-origin resource sharing

Trên đây là những kiến thức giải đáp về SSO là gì và những ưu, nhược điểm của công cụ này. Hy vọng qua bài viết này bạn đã thu nạp được những kiến thức hay và bổ ích cho mình. Đừng quên chia sẻ bài viết hữu ích này đến nhiều người hơn nhé!