Bách Khoa Software
Trang chủ › Giải Pháp Phần Mềm

Hướng dẫn triển khai Single Sign-On (SSO) cho doanh nghiệp

Ban biên tập Bách Khoa Software · · Cập nhật

Single Sign-On (SSO) cho phép nhân viên đăng nhập một lần bằng một tài khoản duy nhất để dùng mọi ứng dụng công ty: email, phần mềm kế toán, CRM, hệ thống nội bộ. Triển khai SSO cho doanh nghiệp gồm ba việc chính: chọn một nhà cung cấp danh tính (Identity Provider, IdP) làm trung tâm, kết nối từng ứng dụng qua giao thức chuẩn như SAML 2.0 hoặc OpenID Connect, và thiết lập chính sách bảo mật như xác thực đa yếu tố cùng quy trình cấp, thu hồi tài khoản. Làm đúng, SSO vừa giúp người dùng tiện hơn vừa giúp bộ phận IT kiểm soát truy cập chặt hơn.

Lợi ích thực tế của SSO

  • Ít mật khẩu hơn: nhân viên không phải nhớ hàng chục mật khẩu, giảm thói quen dùng lại mật khẩu yếu.
  • Thu hồi quyền tức thì: khi nhân viên nghỉ việc, khóa một tài khoản trung tâm là mất quyền vào mọi ứng dụng đã kết nối.
  • Áp chính sách một chỗ: bật MFA, giới hạn quốc gia đăng nhập, yêu cầu thiết bị được quản lý cho mọi ứng dụng cùng lúc.
  • Nhật ký tập trung: biết ai đăng nhập vào đâu, lúc nào, từ thiết bị nào.
  • Giảm yêu cầu hỗ trợ quên mật khẩu, một trong những loại ticket phổ biến nhất của bộ phận IT.

Mặt trái: tài khoản trung tâm trở thành mục tiêu giá trị cao. Nếu bị chiếm, kẻ tấn công vào được mọi thứ. Vì vậy SSO luôn phải đi kèm MFA mạnh.

Các khái niệm cần nắm

  • Identity Provider (IdP): nơi lưu danh tính và thực hiện xác thực, ví dụ Microsoft Entra ID (trước là Azure AD), Google Workspace, Okta, hoặc tự host Keycloak.
  • Service Provider (SP) hay Relying Party: ứng dụng tin tưởng IdP để biết người dùng là ai.
  • Assertion/Token: thông tin IdP gửi cho ứng dụng sau khi xác thực thành công, có chữ ký số để chống giả mạo.
  • Provisioning: tự động tạo, cập nhật, khóa tài khoản trong ứng dụng, thường qua chuẩn SCIM.

SAML 2.0 hay OpenID Connect

Tiêu chíSAML 2.0OpenID Connect (OIDC)
Định dạngXMLJSON, JWT
Nền tảngChuẩn riêng của OASISXây trên OAuth 2.0
Phổ biến ởỨng dụng doanh nghiệp, SaaS lâu đờiỨng dụng web hiện đại, mobile, SPA
Độ phức tạp tích hợpCao hơn (chữ ký XML, metadata)Thấp hơn, nhiều thư viện tốt
Ứng dụng mobileKhông thuận tiệnHỗ trợ tốt với PKCE

Quy tắc chọn đơn giản: dùng giao thức mà ứng dụng hỗ trợ tốt nhất. SaaS phổ biến thường hỗ trợ cả hai. Với ứng dụng nội bộ tự phát triển, OpenID Connect với luồng Authorization Code kèm PKCE là lựa chọn mặc định hợp lý. Đừng tự cài đặt giao thức từ đầu; dùng thư viện đã được kiểm chứng của ngôn ngữ bạn đang dùng.

Lộ trình triển khai từng bước

Bước 1: Kiểm kê ứng dụng và tài khoản

Lập danh sách mọi ứng dụng nhân viên đang dùng, kể cả công cụ do từng phòng tự đăng ký. Với mỗi ứng dụng ghi lại: có hỗ trợ SAML/OIDC không, có hỗ trợ SCIM không, gói hiện tại có tính năng SSO không (nhiều SaaS chỉ mở SSO ở gói doanh nghiệp), ai là chủ sở hữu.

Bước 2: Chọn và chuẩn bị IdP

Nếu công ty đã dùng Microsoft 365 hoặc Google Workspace, tận dụng IdP sẵn có thường là hướng tiết kiệm nhất. Okta và các IdP chuyên dụng mạnh về số lượng tích hợp sẵn và chính sách nâng cao. Keycloak (mã nguồn mở) phù hợp khi muốn tự host và có đội vận hành, nhất là cho ứng dụng nội bộ.

Chuẩn hóa thông tin người dùng trong IdP: email công ty làm định danh chính, phòng ban, chức danh, nhóm. Các nhóm này sẽ dùng để phân quyền ứng dụng.

Bước 3: Bật MFA và chính sách truy cập

Trước khi nối ứng dụng đầu tiên, bật MFA cho toàn bộ tài khoản. Ưu tiên phương thức chống lừa đảo (phishing-resistant) như passkey hoặc khóa bảo mật FIDO2 cho quản trị viên và bộ phận tài chính; ứng dụng xác thực trên điện thoại cho người dùng phổ thông. Hạn chế SMS OTP vì dễ bị tấn công chiếm SIM. Xu hướng thay mật khẩu bằng passkey đang được các hãng lớn thúc đẩy; bài viết về việc tài khoản mới chuyển sang passkey làm mặc định cho thấy hướng đi này.

Bước 4: Thí điểm với vài ứng dụng

Chọn hai ba ứng dụng ít rủi ro, dùng nhiều, hỗ trợ SSO tốt (ví dụ công cụ chat, quản lý dự án). Thí điểm với một nhóm nhỏ, ghi lại các vấn đề: tên người dùng không khớp, tài khoản cũ trùng lặp, phiên đăng nhập hết hạn quá nhanh.

Bước 5: Mở rộng và tắt đăng nhập cũ

Kết nối dần các ứng dụng còn lại. Với mỗi ứng dụng, sau khi SSO chạy ổn, tắt đăng nhập bằng mật khẩu cục bộ (giữ một tài khoản quản trị khẩn cấp được bảo vệ kỹ). Nếu không tắt, nhân viên vẫn có cửa sau để đăng nhập và lợi ích kiểm soát bị mất.

Bước 6: Tự động hóa vòng đời tài khoản

Kết nối IdP với hệ thống nhân sự để khi nhân viên mới vào, tài khoản được tạo tự động với nhóm theo phòng ban; khi chuyển phòng, quyền thay đổi theo; khi nghỉ việc, tài khoản bị khóa ngay ngày cuối. Bài xây dựng hệ thống quản lý nhân sự HRM tự động mô tả cách HRM trở thành nguồn dữ liệu gốc cho quy trình này.

Tích hợp SSO vào ứng dụng nội bộ

Với ứng dụng do đội của bạn tự phát triển:

  • Đăng ký ứng dụng trong IdP, khai báo redirect URI chính xác, không dùng ký tự đại diện.
  • Dùng luồng Authorization Code với PKCE; không dùng luồng Implicit đã lỗi thời.
  • Xác thực chữ ký, issuer, audience và thời hạn của ID token.
  • Ánh xạ nhóm từ IdP sang vai trò trong ứng dụng, không cấp quyền dựa trên dữ liệu người dùng tự nhập.
  • Xử lý đăng xuất: xóa phiên ứng dụng và cân nhắc đăng xuất tập trung tại IdP.
  • Với hệ thống nhiều service, dùng access token có thời hạn ngắn để gọi API, xác minh token tại gateway hoặc từng service.

Các nguyên tắc lập trình an toàn khác cho ứng dụng nội bộ được tổng hợp trong bài giải pháp bảo mật thông tin và phát triển phần mềm an toàn.

Vận hành sau triển khai

  • Đưa nhật ký đăng nhập của IdP vào hệ thống giám sát, cảnh báo khi có đăng nhập bất thường (quốc gia lạ, nhiều lần thất bại, thiết bị mới với tài khoản quản trị).
  • Rà soát quyền truy cập định kỳ theo quý: ai đang có quyền vào ứng dụng tài chính, ai là quản trị viên.
  • Theo dõi hạn chứng chỉ ký SAML; chứng chỉ hết hạn có thể khiến cả công ty không đăng nhập được.
  • Chuẩn bị kế hoạch khi IdP gặp sự cố: tài khoản khẩn cấp, liên hệ hỗ trợ, thông báo nội bộ.

Câu hỏi thường gặp

SSO có làm tăng rủi ro bảo mật vì chỉ cần một mật khẩu không?

Nếu chỉ dùng mật khẩu thì rủi ro tập trung hơn. Khi kết hợp MFA mạnh, chính sách truy cập theo điều kiện và giám sát đăng nhập, SSO thường an toàn hơn nhiều so với hàng chục mật khẩu rời rạc mà người dùng hay đặt trùng nhau.

Doanh nghiệp nhỏ có cần SSO không?

Doanh nghiệp nhỏ dùng Google Workspace hoặc Microsoft 365 có thể bật đăng nhập bằng tài khoản công ty cho các SaaS hỗ trợ, gần như không tốn thêm chi phí. Lợi ích lớn nhất là thu hồi quyền nhanh khi nhân sự nghỉ.

SSO khác với dùng chung một mật khẩu cho nhiều ứng dụng thế nào?

Với SSO, mật khẩu chỉ được nhập tại IdP, các ứng dụng không bao giờ nhìn thấy nó mà chỉ nhận token đã ký. Dùng chung mật khẩu thì mỗi ứng dụng đều lưu và có thể làm lộ mật khẩu đó.

Ứng dụng cũ không hỗ trợ SAML hay OIDC thì làm sao?

Có thể đặt ứng dụng sau một reverse proxy có xác thực (identity-aware proxy) để buộc đăng nhập qua IdP trước khi vào. Nếu không được, cân nhắc thay thế ứng dụng hoặc ít nhất quản lý mật khẩu của nó trong trình quản lý mật khẩu doanh nghiệp.

Bài liên quan