Chăm sóc khách hàng
Đăng nhập một lần (SSO) cho phần mềm chăm sóc khách hàng đa kênh: hướng dẫn OpenID Connect cho đội ngũ hỗ trợ
Nhân viên đọc tin nhắn khách hàng cả ngày nên đăng nhập bằng tài khoản công ty, không dùng thêm một mật khẩu riêng. Bài này giải thích SSO bằng OpenID Connect hoạt động ra sao, cần quyết định gì trước khi bật, và cách cài đặt trên bản MonoChat on-premise.
Đội ngũ MonoChat Cập nhật: 10 phút đọc
Trong trang này
- Vì sao cách đăng nhập quan trọng với đội ngũ hỗ trợ
- Đăng nhập OpenID Connect hoạt động như thế nào
- Quyết định năm điều này trước khi bật SSO
- Cài đặt SSO trên bản MonoChat on-premise
- Nhân viên hiện có: tài khoản được liên kết ra sao
- SSO là danh tính; vai trò mới là quyền truy cập
- Những giới hạn cần tính đến
- SSO nằm ở đâu trong MonoChat
- Nguồn
Đăng nhập một lần (SSO) cho phần mềm nhắn tin chăm sóc khách hàng nghĩa là nhân viên của bạn đăng nhập bằng tài khoản công ty tại nhà cung cấp danh tính, như Microsoft Entra ID, Okta, Keycloak, AD FS hoặc Google Workspace, thay vì dùng một mật khẩu riêng. Chuẩn đứng sau đó là OpenID Connect (OIDC). Trên bản MonoChat on-premise, bạn cài đặt một lần cho cả hệ thống, giới hạn theo tên miền email của công ty, và có thể biến nó thành cách đăng nhập duy nhất.
Đội ngũ hỗ trợ có lý do riêng để quan tâm. Tài khoản của một nhân viên mở ra mọi cuộc trò chuyện trên Facebook Messenger, Instagram hay WhatsApp mà họ được phép xem: họ tên, số điện thoại, chi tiết đơn hàng, đôi khi cả câu hỏi về sức khỏe hoặc thanh toán. Tài khoản đó nên tuân theo cùng quy tắc với các tài khoản khác trong công ty, và phải ngừng hoạt động ngay trong ngày người đó nghỉ việc.
Vì sao cách đăng nhập quan trọng với đội ngũ hỗ trợ
Thông tin đăng nhập bị đánh cắp hoặc lạm dụng vẫn là con đường phổ biến nhất để xâm nhập vào một doanh nghiệp. Báo cáo Điều tra vi phạm dữ liệu (Data Breach Investigations Report) 2025 của Verizon, phân tích 12.195 vụ vi phạm đã được xác nhận, cho thấy lạm dụng thông tin xác thực (22%) và khai thác lỗ hổng (20%) là hai vector tấn công ban đầu hàng đầu.
Một nền tảng nhắn tin có mật khẩu riêng sẽ thêm cho mỗi nhân viên một bộ thông tin đăng nhập nữa: thêm một mật khẩu dễ bị dùng lại, thêm một tài khoản dễ bị quên khi có người nghỉ việc, thêm một lần đăng nhập mà quy tắc xác thực đa yếu tố (MFA) và truy cập có điều kiện của bạn không áp dụng tới. Với SSO, nền tảng không bao giờ thấy mật khẩu. Nhà cung cấp danh tính của bạn kiểm tra mật khẩu, áp dụng MFA và chính sách truy cập, rồi báo cho nền tảng biết ai vừa đăng nhập.
Đăng nhập OpenID Connect hoạt động như thế nào
OpenID Connect là lớp danh tính xây trên OAuth 2.0. MonoChat dùng luồng mã ủy quyền (authorization code flow):
- Nhân viên bấm nút SSO trên trang đăng nhập. MonoChat mở trang đăng nhập của nhà cung cấp danh tính trong một cửa sổ bật lên.
- Nhân viên đăng nhập tại đó, kèm MFA và các chính sách của bạn.
- Nhà cung cấp danh tính đưa trình duyệt quay lại MonoChat cùng một mã dùng một lần.
- Máy chủ MonoChat đổi mã đó lấy ID token, theo kiểu máy chủ với máy chủ. Các token không đi qua trình duyệt.
- MonoChat kiểm tra ID token rồi cho nhân viên đăng nhập.
Theo lời của đặc tả OpenID Connect, ID token là “a security token that contains Claims about the Authentication of an End-User” (token bảo mật chứa các claim về việc xác thực người dùng cuối). MonoChat chỉ chấp nhận token khi:
- nó được ký bằng một trong các khóa của nhà cung cấp danh tính, đọc từ tài liệu discovery (
<issuer>/.well-known/openid-configuration) ở mỗi lần đăng nhập; - issuer (
iss) là issuer của bạn, audience (aud) là client ID của MonoChat và thời hạn (exp) chưa qua; - nó mang
noncemà MonoChat đã gửi kèm yêu cầu, giúp gắn token với đúng lần đăng nhập này và chặn việc phát lại; - nó chứa địa chỉ email của người đó, và nhà cung cấp không cho biết địa chỉ ấy chưa được xác minh.
Yêu cầu cũng dùng PKCE (S256) và giá trị state; một yêu cầu đăng nhập có hiệu lực trong 10 phút và chỉ dùng được một lần.
Quyết định năm điều này trước khi bật SSO
| Quyết định | Lựa chọn | Gợi ý của chúng tôi cho đội ngũ hỗ trợ |
|---|---|---|
| Ai được đăng nhập | Mọi tên miền, hoặc chỉ tên miền email của công ty | Giới hạn theo tên miền của bạn |
| Điều gì xảy ra ở lần đăng nhập đầu tiên | Tự tạo tài khoản, hoặc chỉ nhận người đã được mời | Tự tạo tài khoản nếu nhà cung cấp danh tính của bạn đã kiểm soát ai đang làm việc trong công ty |
| Tài khoản hiện có | Liên kết SSO ở lần đăng nhập đầu khi email đã xác minh, hoặc sau một lần đăng nhập bằng mật khẩu | Tùy nhà cung cấp của bạn có gửi email_verified hay không |
| Các phương thức đăng nhập khác | Giữ mật khẩu và đăng nhập mạng xã hội, hoặc chỉ SSO | Chỉ SSO, sau khi mọi người đã liên kết SSO |
| Ai được mở workspace mới | Bất kỳ ai có tài khoản, hoặc chỉ người có vai trò phù hợp | Tắt việc tự do tạo workspace trong bản cài đặt của công ty |
Hãy ghi lại các quyết định này trước khi thay đổi bất kỳ cài đặt nào. Đó là những câu hỏi bộ phận bảo mật của bạn sẽ đặt ra, và câu trả lời quyết định bạn cần những cài đặt nào.
Cài đặt SSO trên bản MonoChat on-premise
SSO được cài đặt cho cả hệ thống trong phần cài đặt máy chủ, không phải cho từng workspace. Tài liệu đầy đủ nằm ở trang đăng nhập một lần trong trung tâm trợ giúp; dưới đây là bản rút gọn.
1. Đăng ký MonoChat tại nhà cung cấp danh tính
Tạo một ứng dụng web có client secret, và cấu hình:
- redirect URI
https://<your MonoChat domain>/api/oauth/oidc/redirect; - authorization code grant;
- các scope
openid email profile; - xác thực client với secret gửi theo HTTP Basic (
client_secret_basic).
Hãy bảo đảm ID token có claim email, và ghi lại client ID, client secret cùng issuer.
2. Sao chép issuer thật chính xác
Issuer là giá trị issuer trong tài liệu discovery của nhà cung cấp. Các dạng thường gặp:
| Nhà cung cấp danh tính | Issuer |
|---|---|
| Microsoft Entra ID | https://login.microsoftonline.com/<tenant id>/v2.0 |
| Okta | https://<your Okta domain>/oauth2/default hoặc https://<your Okta domain> |
| Keycloak | https://<your Keycloak host>/realms/<realm> |
| AD FS 2016 trở lên | https://<your AD FS host>/adfs |
| Google Workspace | https://accounts.google.com |
Mở <issuer>/.well-known/openid-configuration trong trình duyệt và sao chép giá trị từng ký tự một, kể cả dấu gạch chéo ở cuối nếu có. MonoChat từ chối mọi lần đăng nhập khi hai giá trị khác nhau, và đây là lý do phổ biến nhất khiến lần thử đầu tiên thất bại.
3. Thêm cài đặt và khởi động lại
Phần công khai (issuer, client ID, đường dẫn redirect, scope và chữ trên nút) nằm trong public.oauth.oidc; client secret nằm trong oauth.oidc và chỉ ở trên máy chủ. Hai tùy chọn ở đó phản ánh các quyết định của bạn trong bảng trên:
autoCreateAccounts: truetạo tài khoản MonoChat ở lần đăng nhập SSO đầu tiên của một người, kể cả khi đăng ký chỉ dành cho người được mời;allowedEmailDomains: ["yourcompany.com"]từ chối mọi địa chỉ thuộc tên miền khác. Với Google Workspace, MonoChat kiểm tra tên miền Workspace của tài khoản (claimhd) thay vì địa chỉ email, vì một tài khoản Google cá nhân có thể dùng địa chỉ thuộc bất kỳ tên miền nào.
Nút hiển thị “Đăng nhập bằng SSO” theo ngôn ngữ của từng người, hoặc theo nhãn bạn đặt, chẳng hạn “Đăng nhập bằng Northwind SSO”.
4. Biến SSO thành phương thức duy nhất, một cách an toàn
Khi mọi người đã liên kết SSO, hãy đặt các phương thức đăng nhập được phép (public.auth.methods) thành ["oidc"]. Trang đăng nhập khi đó chỉ hiện nút SSO, còn máy chủ từ chối đăng nhập bằng mật khẩu và mạng xã hội. Người dùng root (super user) vẫn đăng nhập được bằng mật khẩu tại /auth/signin?fallback=1, nên khi nhà cung cấp danh tính ngừng hoạt động, hệ thống sẽ không bị khóa. Để các tài khoản SSO mới không tự mở workspace riêng, hãy đặt public.disableTenantCreation thành true.
5. Kiểm thử bốn trường hợp đăng nhập
- Người đã có tài khoản: cửa sổ bật lên đóng lại và họ vào được hệ thống.
- Người chưa có tài khoản: tài khoản được tạo, hoặc bị từ chối nếu bạn chưa bật tự tạo tài khoản.
- Người thuộc tên miền khác: bị từ chối, nếu bạn đã giới hạn tên miền.
- Đăng nhập bằng mật khẩu khi đã bật chỉ-SSO: bị từ chối, trong khi đường dự phòng của root vẫn hoạt động.
Nhân viên hiện có: tài khoản được liên kết ra sao
Phần lớn các đội ngũ bật SSO khi nhân viên đã có tài khoản MonoChat. MonoChat liên kết SSO với tài khoản hiện có dùng cùng địa chỉ email theo một trong hai cách:
- Tự động, ở lần đăng nhập SSO đầu tiên, khi bản cài đặt cho phép gộp tài khoản và ID token cho biết địa chỉ đã được xác minh (
email_verified: true). - Sau một lần đăng nhập bằng mật khẩu, trong mọi trường hợp còn lại: MonoChat yêu cầu người đó đăng nhập bằng mật khẩu một lần và liên kết SSO ngay khi đó. Chấp nhận lời mời vào một workspace cũng liên kết tài khoản.
Microsoft Entra ID và AD FS không gửi email_verified. Với hai nhà cung cấp này, hãy giữ đăng nhập bằng mật khẩu cho đến khi mọi người đã liên kết SSO, hoặc mời lại họ, rồi mới chuyển sang chỉ-SSO.
SSO là danh tính; vai trò mới là quyền truy cập
Đăng nhập chỉ cấp cho một người một tài khoản, không cấp quyền vào các cuộc trò chuyện của bạn. Một tài khoản MonoChat có thể thuộc nhiều workspace, và người dùng đăng nhập trước rồi mới chọn workspace. Một người chỉ thấy workspace sau khi workspace đó mời họ và gán vai trò, và vai trò quyết định họ vào được kênh, cuộc trò chuyện và cài đặt nào. Xem vai trò và phân quyền hộp thư đội ngũ để biết cách thiết lập.
Cách tách bạch này chính là điều kiểm toán viên muốn thấy:
- Người mới vào: nhà cung cấp danh tính tạo người đó; quản trị viên workspace mời họ và chọn vai trò.
- Người chuyển vị trí: đổi vai trò hoặc nhóm làm việc trong MonoChat; cách đăng nhập không đổi.
- Người nghỉ việc: vô hiệu hóa người đó tại nhà cung cấp danh tính, và xóa họ khỏi workspace trong MonoChat.
Những giới hạn cần tính đến
- Ứng dụng di động. Ứng dụng MonoChat trên Android và iOS chưa có SSO. Nếu SSO là phương thức đăng nhập duy nhất, nhân viên sẽ không đăng nhập được trên điện thoại, vì vậy hãy giữ một phương thức khác cho người dùng di động hoặc lên kế hoạch cho các ca làm chỉ trên máy tính.
- Đăng xuất. Đăng xuất khỏi MonoChat không đăng xuất người đó khỏi nhà cung cấp danh tính, và đăng xuất ở đó cũng chưa đăng xuất họ khỏi MonoChat. Vô hiệu hóa người nghỉ việc tại nhà cung cấp danh tính sẽ chặn các lần đăng nhập mới; hãy xóa họ khỏi workspace nữa.
- Mạng. Trình duyệt của mọi người phải truy cập được
/api/oauth/oidc/authorizevà đường dẫn redirect, còn máy chủ MonoChat phải truy cập được tài liệu discovery, token endpoint và bộ khóa của nhà cung cấp qua HTTPS. Nếu bạn cũng giới hạn bản cài đặt theo IP, hãy lưu ý các đường dẫn này.
SSO nằm ở đâu trong MonoChat
SSO được cấu hình trong phần cài đặt máy chủ của cả một bản cài đặt, nên hiện nay nó thuộc về MonoChat on-premise: tùy chọn Enterprise dành cho các đội ngũ chạy nền tảng trên máy chủ của riêng mình, với LLM và cơ sở dữ liệu vector riêng. Trang Enterprise giải thích về tùy chọn on-premise, còn trang bảo mật nói về phân quyền theo vai trò, cách ly workspace và các chứng nhận. Về phần dữ liệu khi triển khai AI, xem checklist quyền riêng tư cho chatbot AI.
Nếu muốn dùng thử sản phẩm trước, gói Basic miễn phí tại app.monochat.ai cho bạn một nhân viên và một kênh.
Nguồn
- OpenID Connect Core 1.0, OpenID Foundation, truy cập ngày 4/11/2026
- Thông báo báo cáo Verizon 2025 Data Breach Investigations Report, truy cập ngày 4/11/2026
- Trung tâm trợ giúp MonoChat: Đăng nhập một lần cho bản cài đặt on-premise, truy cập ngày 4/11/2026
- Nhật ký thay đổi MonoChat 3.8.43, ngày 2/11/2026
Áp dụng với MonoChat