SSO (Single Sign-On, đăng nhập một lần) là cách để nhân viên đăng nhập một lần bằng tài khoản công ty, rồi mở được email, phần mềm kế toán, CRM, kho, chấm công mà không phải gõ lại mật khẩu cho từng phần mềm. Một nơi giữ danh sách người được vào, các phần mềm khác tin nơi đó.
Nhận định của bài: giá trị lớn nhất của SSO không nằm ở việc đỡ gõ mật khẩu mỗi sáng. Nó nằm ở ngày một nhân viên nghỉ việc: khoá một tài khoản là người đó mất quyền vào mọi phần mềm cùng lúc. Nếu công ty chưa có nhu cầu đó, SSO thường là khoản tiền trả sớm.
Nghĩa bằng lời thường: một cổng bảo vệ thay cho mười ổ khoá
Không có SSO, mỗi phần mềm tự giữ danh sách người dùng và mật khẩu riêng. Công ty 30 người dùng 8 phần mềm là 240 cặp tên và mật khẩu nằm rải ở 8 nơi. Người quản trị mỗi phần mềm tự thêm, tự xoá. Nhân viên thường đặt cùng một mật khẩu cho mọi nơi, và khi một nơi bị lộ thì các nơi khác cũng hở.
Có SSO, danh sách người dùng nằm ở một chỗ gọi là nhà cung cấp danh tính (identity provider, viết tắt IdP). Với doanh nghiệp Việt, IdP hay gặp nhất là tài khoản Google Workspace hoặc Microsoft 365 mà công ty đã có sẵn cho email. Khi nhân viên mở phần mềm CRM, CRM không hỏi mật khẩu mà chuyển họ sang trang đăng nhập Google hoặc Microsoft. Đăng nhập xong, IdP gửi lại cho CRM một tờ giấy xác nhận có chữ ký: người này là ai, thuộc phòng nào, giấy có hạn tới mấy giờ.
Tờ giấy xác nhận đó có hai chuẩn phổ biến. SAML 2.0 được tổ chức tiêu chuẩn OASIS phê duyệt ngày 01/03/2005, dùng định dạng XML, hay gặp ở phần mềm doanh nghiệp đời cũ và các gói Enterprise. OpenID Connect là giao thức xác thực xây trên nền OAuth 2.0 (hai văn bản RFC 6749 và 6750 của IETF), dùng mã thông báo dạng JWT, hay gặp ở ứng dụng web và di động mới. Chủ doanh nghiệp không cần nhớ chi tiết, chỉ cần biết phần mềm mình mua hỗ trợ chuẩn nào, vì hai bên phải nói cùng một chuẩn thì mới nối được.
Ảnh trên cho thấy vì sao giấy xác nhận luôn có hạn. Nếu một mã thông báo sống vài ngày, người đã bị khoá tài khoản vẫn dùng được phần mềm tới khi mã hết hạn. Chuyện chọn lưu phiên đăng nhập ở máy chủ hay trong mã thông báo, và cái giá khi muốn đá một người ra ngay lập tức, được giải thích kỹ ở bài phiên đăng nhập và JWT khác nhau thế nào trên blog của người sáng lập ALODEV.
SSO trong báo giá: thường là một dòng ở gói đắt nhất
Chủ doanh nghiệp hay gặp SSO ở ba chỗ, và mỗi chỗ kéo theo tiền theo một cách khác nhau.
- Bảng giá phần mềm thuê bao (SaaS). SSO thường ghi là "SAML SSO" hoặc "Single sign-on" và nằm ở gói Enterprise hay Business. Muốn có SSO thì cả công ty phải lên gói cao, trả giá cao cho mọi người dùng chứ không chỉ cho một tính năng.
- Báo giá phần mềm viết theo yêu cầu. SSO thường là một hạng mục "Tích hợp đăng nhập Google/Microsoft" tính theo ngày công. Nếu không ghi rõ chuẩn (SAML hay OpenID Connect), phạm vi (chỉ đăng nhập, hay cả đồng bộ tạo và khoá tài khoản) và ai cấu hình phía IdP, hạng mục này dễ phát sinh.
- Gói của chính nhà cung cấp danh tính. Tài khoản Google Workspace hay Microsoft 365 công ty đang trả đã có một phần tính năng SSO. Các tính năng quản trị sâu hơn như chặn đăng nhập theo điều kiện (chỉ cho vào từ máy công ty, từ Việt Nam) thường nằm ở gói trả thêm.
Phép tính đơn giản với số trong ảnh: công ty 30 người dùng GitHub gói Team trả 30 x 4 = 120 USD mỗi tháng. Muốn có SAML SSO trên chính dịch vụ này, gói Enterprise từ 30 x 21 = 630 USD mỗi tháng, gấp hơn năm lần. Gói Enterprise còn nhiều tính năng khác, nhưng nếu lý do duy nhất để nâng gói là SSO, đó là khoản chênh cần đặt lên bàn trước khi ký.
Phía nhà cung cấp danh tính thì khác. Trang giá Microsoft Entra ghi bản Entra ID Free đi kèm các gói Microsoft cloud như Microsoft 365, có "unlimited SSO across any SaaS app", tức SSO không giới hạn số ứng dụng. Các gói trả thêm P1 (7 USD), P2 (10 USD) và Entra Suite (12 USD mỗi người mỗi tháng, trả theo năm) bán các tính năng kiểm soát truy cập sâu hơn. Nghĩa là với công ty đã dùng Microsoft 365, cổng bảo vệ đã có sẵn; tiền thường phát sinh ở phía từng phần mềm muốn nối vào cổng đó.
Rủi ro nằm ở ngày nghỉ việc và ở một điểm hỏng chung
Rủi ro lớn nhất khi không có SSO là tài khoản mồ côi: nhân viên đã nghỉ nhưng tài khoản vẫn còn ở vài phần mềm vì không ai nhớ họ từng được cấp. Người đó vẫn đăng nhập được vào CRM để xem danh sách khách, vào ổ lưu trữ để tải báo giá. Với SSO, quy trình nghỉ việc rút về một việc: khoá tài khoản ở IdP. Phần mềm nào nối vào IdP đều từ chối người đó ở lần đăng nhập kế tiếp, hoặc khi mã thông báo hiện tại hết hạn.
Muốn việc khoá xảy ra ngay, không chờ hết hạn, phần mềm phải hỗ trợ thêm đồng bộ tài khoản, thường gọi theo chuẩn SCIM (trên bảng giá GitHub ở trên, dòng "User provisioning through SCIM" cũng nằm ở gói Enterprise). SSO chỉ lo việc đăng nhập; SCIM lo việc tạo, sửa, khoá tài khoản tự động. Nhiều báo giá ghi "có SSO" nhưng không có SCIM, và người mua chỉ phát hiện khi cần khoá gấp một người.
Mặt trái của SSO là một điểm hỏng chung. Nếu IdP ngừng chạy, hoặc tài khoản quản trị IdP bị chiếm, mọi phần mềm nối vào đều bị ảnh hưởng cùng lúc. Vì thế SSO luôn phải đi kèm xác thực hai lớp cho mọi người, và ít nhất hai tài khoản quản trị IdP có đăng nhập khẩn cấp không phụ thuộc SSO.
Câu nên hỏi nhà cung cấp trước khi ký
- Phần mềm hỗ trợ SSO theo chuẩn nào: SAML 2.0, OpenID Connect, hay chỉ nút "Đăng nhập bằng Google"? Có nối được với Google Workspace hoặc Microsoft 365 mà công ty đang dùng không?
- SSO có ở gói chúng tôi định mua không? Nếu chỉ có ở gói cao hơn, chênh lệch mỗi người mỗi tháng là bao nhiêu, và có mua riêng tính năng SSO được không?
- Khi khoá tài khoản ở Google/Microsoft, người đó mất quyền vào phần mềm sau bao lâu? Có hỗ trợ SCIM để tự khoá ngay không?
- Sau khi bật SSO, đăng nhập bằng mật khẩu riêng có tắt được cho mọi người không, kể cả quản trị viên? Tài khoản khẩn cấp nào còn giữ lại?
- Với phần mềm viết theo yêu cầu: hạng mục SSO gồm những gì (đăng nhập, phân quyền theo nhóm, khoá tự động), ai cấu hình phía IdP, và kiểm thử nghiệm thu thế nào?
- Nếu sau này công ty đổi từ Google sang Microsoft hoặc ngược lại, đổi IdP có mất dữ liệu người dùng trong phần mềm không, và tốn bao nhiêu công?
Câu thứ hai quan trọng nhất về tiền. Câu thứ ba quan trọng nhất về rủi ro. Nhiều chủ doanh nghiệp hỏi câu thứ nhất rồi dừng, và chỉ biết SSO nằm ở gói khác khi đã triển khai xong.
Khi nào chưa cần SSO
- Công ty dưới khoảng 15 người, dùng ba bốn phần mềm, ít người vào ra. Một bảng theo dõi ai được cấp tài khoản ở đâu, cộng một trình quản lý mật khẩu dùng chung, đủ an toàn và rẻ hơn nâng gói.
- Phần lớn phần mềm công ty dùng đã nằm trong một bộ duy nhất (ví dụ toàn bộ là Google Workspace hoặc Microsoft 365). Đăng nhập một lần đã có sẵn trong bộ đó.
- Phần mềm chỉ một hai người dùng, như phần mềm kế toán của phòng kế toán hai người. Khoá tay khi nghỉ việc nhanh hơn cấu hình SSO.
- Lý do duy nhất để nâng gói Enterprise là SSO, trong khi công ty không có yêu cầu kiểm toán hay yêu cầu bảo mật từ khách hàng lớn. Khoản chênh nhiều khi lớn hơn rủi ro nó che.
Ngược lại, nên tính SSO khi công ty có trên vài chục người, có nhân viên thời vụ vào ra thường xuyên, dùng nhiều phần mềm chứa dữ liệu khách hàng, hoặc khách hàng lớn yêu cầu bằng chứng kiểm soát truy cập. Khi đó số giờ quản trị viên tiết kiệm và rủi ro tài khoản mồ côi đủ lớn để trả cho gói cao.
Câu hỏi thường gặp
SSO là viết tắt của gì?
SSO là Single Sign-On, tiếng Việt thường gọi là đăng nhập một lần: đăng nhập một tài khoản để dùng nhiều phần mềm, thay vì mỗi phần mềm một mật khẩu.
Nút "Đăng nhập bằng Google" có phải là SSO không?
Có, đó là một dạng SSO dùng OpenID Connect, nhưng thường chỉ lo việc đăng nhập. Với doanh nghiệp, cần kiểm thêm phần mềm có giới hạn chỉ cho tài khoản tên miền công ty vào hay không, và có khoá tự động khi tài khoản Google bị khoá hay không.
SSO có làm công ty an toàn hơn không?
An toàn hơn ở khâu quản lý người vào ra, vì khoá một chỗ là khoá hết. Nhưng nó tạo một điểm hỏng chung, nên phải bật xác thực hai lớp cho mọi tài khoản và bảo vệ kỹ tài khoản quản trị của nhà cung cấp danh tính.
SAML và OpenID Connect khác nhau thế nào?
Cả hai đều chuyển giấy xác nhận danh tính giữa nhà cung cấp danh tính và phần mềm. SAML 2.0 (OASIS, 2005) dùng XML, phổ biến ở phần mềm doanh nghiệp đời cũ; OpenID Connect xây trên OAuth 2.0, dùng JWT, phổ biến ở ứng dụng web và di động mới.
Làm SSO cho phần mềm viết riêng tốn bao lâu?
Không có con số chung; phụ thuộc chuẩn, số vai trò cần ánh xạ và có làm đồng bộ tài khoản hay không. Nên yêu cầu nhà cung cấp tách riêng hạng mục SSO trong báo giá, ghi rõ phạm vi và tiêu chí nghiệm thu, thay vì gộp vào "phân hệ tài khoản".
