Đã đăng vào khoảng 4 giờ trước 4 phút đọc

[System Design] Single Sign-On (SSO) là gì? Giải mã cơ chế "Một chìa khóa mở mọi cánh cửa"

Hãy tưởng tượng bạn làm việc tại môt tập đoàn lớn. Bạn có một tài khoản Email, một tài khoản Slack, một tài khoản Jira, và một hệ thống quản lý nhân sự. Sẽ thật ác mộng nếu mỗi sáng bạn phải dăng nhập 4 lần với 4 mật khẩu khác nhau.

Single Sign-On (SSO) ra đời để giải quyết vấn đề đó. Chỉ cần đăng nhập một lần duy nhất, bạn có thể truy cập vào tất cả các ứng dụng trong hệ thống mà không cần nhập lại mật khẩu.

1. SSO hoạt động như thế nào? (High-level)

Cốt lõi của SSO không phải là chia sẻ mật khẩu, mà là chia sẻ Sự tin tưởng (Trust).

Trong mô hình SSO, chúng ta có 3 thành phần chính:

User: Người dùng muốn truy cập dịch vụ.
Service Provider (SP): Các ứng dụng con (như Gmail, Slack, App của bạn).
Identity Provider (IdP): Hệ thống trung tâm quản lý danh tiinsh (như Google, Facebook, Okta, Keycloak).

Quy trình diễn ra:

Người dùng truy cập vào app A (SP)
App A thấy người dùng chưa đăng nhập, liền "đá" (redirect) người dùng sang IdP.
Người dùng đăng nhập tại IdP
IdP xác nhận đúng, gửi một "tấm thẻ thông hành" (Token/Ticket) về cho App A.
App A kiểm tra thẻ này, nếu đúng thì cho người dùng vào.
Khi người dùng sang App B, App B cũng hỏi IdP. Vì IdP đã biết người dùng này rồi, nó cấp thẻ luôn mà không bắt nhập lại mật khẩu.

2. Các giao thức SSO phổ biến nhất

Đừng nhầm lẫn giữa SSO và các giao thức. SSO là khái niệm, còn dưới đây là công cụ để thực hiện nó:

A. SAML (Security Assertion Markup Language)

Sử dụng định dạng XML để trao đổi dữ liệu.

Phổ biến trong các doanh nghiệp lớn (Enterprise) vì tính bảo mật cực cao.

Ví dụ: Đăng nhập vào hệ thống công ty bằng tài khoản Microsoft Azure AD.

B. OIDC (OpenID Connect)

Xây dựng trên nền tảng OAuth 2.0.

Sử dụng JSON Web Token (JWT), rất nhẹ và thân thiện với ứng dụng Web/Mobile hiện đại.

Ví dụ: Nút "Login with Google" hoặc "Login with Facebook".

C. CAS (Central Authentication Service)

Một giao thức đời cũ nhưng vẫn rất mạnh mẽ, thường dùng trong môi trường giáo dục (Đại học).

3. Tại sao doanh nghiệp "phát cuồng" vì SSO?

Lợi ích đối với User	Lợi ích đối với Admin/Dev
Trải nghiệm mượt mà: Không cần nhớ hàng chục mật khẩu.	Bảo mật tập trung: Chỉ cần bảo vệ một nơi duy nhất (IdP).
Tiết kiệm thời gian: Giảm bớt các bước gõ phím phiền phức.	Dễ dàng quản lý: Khi nhân viên nghỉ việc, chỉ cần khóa 1 tài khoản là xong.
Giảm Stress: Không còn lo bị khóa tài khoản do quên pass.	Giảm tải hỗ trợ: Giảm 50% số lượng ticket "Quên mật khẩu".

4. Những thách thức và rủi ro (The Dark Side)

Dù rất xịn xò, SSO vẫn có điểm yếu chí mạng: "Trứng bỏ chung một giỏ".

Single Point of Failure: Nếu hệ thống IdP (trung tâm) bị sập, toàn bộ các app con đều "văng" ra ngoài, không ai đăng nhập được.

Rủi ro tài khoản: Nếu hacker chiếm được tài khoản SSO, chúng sẽ có quyền truy cập vào tất cả các ứng dụng của bạn.

Giải pháp: Luôn luôn đi kèm với MFA (Multi-Factor Authentication - Xác thực 2 lớp).

5. Ví dụ thực tế: Luồng OIDC (OpenID Connect)

User nhấn "Login with Google" trên ứng dụng của bạn.

Ứng dụng chuyển hướng User tới Google Login kèm theo client_id và redirect_uri.

User nhập mật khẩu Google thành công.

Google gửi một Authorization Code về lại ứng dụng của bạn qua redirect_uri.

Backend của bạn cầm code này "hỏi" Google: "Code này đúng không? Cho tôi xin thông tin User".

Google trả về một ID Token (chứa tên, email...).

Ứng dụng của bạn tin tưởng Google và tạo session cho User. Xong!

Lời kết

SSO không chỉ là một tính năng, nó là một tiêu chuẩn về bảo mật và trải nghiệm người dùng trong thời đại số. Nếu bạn đang xây dựng một hệ thống gồm nhiều ứng dụng vệ tinh, hãy cân nhắc triển khai SSO ngay từ đầu.