客户服务
客服系统单点登录（SSO）：面向客服团队的 OpenID Connect 配置指南
每天处理客户会话的客服，应该用公司账号登录，而不是再记一套单独的密码。本文讲解 OpenID Connect SSO 的工作方式、开启前需要先定的事项，以及如何在本地部署（on-premise）的 MonoChat 上完成配置。
MonoChat 团队 更新于: 2 分钟阅读
本页内容
客服系统的单点登录（SSO），是指客服用自己在身份提供商处的公司账号登录，例如 Microsoft Entra ID、Okta、Keycloak、AD FS 或 Google Workspace，而不是再用一套单独的密码。它背后的标准是 OpenID Connect（OIDC）。在本地部署（on-premise）的 MonoChat 上，您只需为整套部署配置一次，把它限制在公司的邮箱域名内，还可以让它成为唯一的登录方式。
客服团队尤其有理由重视这件事。一个客服账号能打开他可见范围内的所有 WhatsApp、Instagram 和 Messenger 会话：姓名、电话号码、订单详情，有时还有健康或付款方面的问题。这个账号应当遵守与公司其他账号相同的规则，并且在员工离职当天就失效。对于团队成员分布在不同城市、轮班覆盖不同时区的出海企业，这一点更加重要。
为什么客服团队要重视登录方式
被盗用或滥用的凭据，仍然是攻击者进入企业最常见的途径。Verizon 2025 年数据泄露调查报告分析了 12,195 起已确认的数据泄露事件，发现凭据滥用（22%）和漏洞利用（20%）是最主要的初始攻击途径。
自带一套密码的客服系统，会给每位客服多增加一组凭据：多一个可能被重复使用的密码，多一个有人离职时容易被遗忘的账号，多一个不受您的多因素认证和条件访问规则覆盖的登录入口。使用 SSO 后，客服系统不会接触密码。由您的身份提供商校验密码、执行 MFA 和访问策略，再告诉客服系统是谁登录了。
OpenID Connect 登录是怎么工作的
OpenID Connect 是建立在 OAuth 2.0 之上的身份层。MonoChat 使用的是授权码流程（authorization code flow）：
- 客服在登录页点击 SSO 按钮，MonoChat 在弹出窗口中打开您的身份提供商的登录页。
- 客服在那里登录，并经过您设置的 MFA 和策略。
- 身份提供商带着一次性代码，把浏览器重定向回 MonoChat。
- MonoChat 服务器以服务器对服务器的方式，用这个代码换取 ID 令牌。令牌不会经过浏览器。
- MonoChat 校验 ID 令牌，并让客服登录。
按照 OpenID Connect 规范的说法，ID 令牌是“a security token that contains Claims about the Authentication of an End-User”。只有同时满足以下条件，MonoChat 才会接受它：
- 它由您的身份提供商的某个密钥签名，该密钥在每次登录时都从其发现文档（
<issuer>/.well-known/openid-configuration）中读取； - 它的签发者（
iss）是您的 issuer，受众（aud）是 MonoChat 的 client ID，并且有效期（exp）未过； - 它带有 MonoChat 随请求发出的
nonce，这个值把令牌和本次登录绑定在一起，可以防止重放； - 它包含此人的电子邮件地址，并且身份提供商没有声明该地址未经验证。
请求还使用了 PKCE（S256）和 state 值，每个登录请求的有效期为 10 分钟，且只能使用一次。
开启 SSO 之前，先定下这五件事
| 决策 | 可选项 | 我们对客服团队的建议 |
|---|---|---|
| 谁可以登录 | 所有域名，或仅限公司的邮箱域名 | 限制为公司自己的域名 |
| 首次登录时怎么处理 | 自动创建账号，或只接受受邀的人 | 如果谁在公司工作已经由身份提供商控制，就自动创建账号 |
| 已有账号 | 邮箱已验证时在首次登录时关联 SSO，或在一次密码登录之后关联 | 取决于您的身份提供商是否发送 email_verified |
| 其他登录方式 | 保留密码和社交账号登录，或仅限 SSO | 等所有人都关联了 SSO 之后，改为仅限 SSO |
| 谁可以创建新工作区 | 任何有账号的人，或仅限拥有相应角色的人 | 在企业内部部署中关闭开放的工作区创建 |
请在修改任何设置之前把这些写下来。这些正是您的安全团队会问的问题，答案也决定了您需要哪些设置。
在本地部署的 MonoChat 上设置 SSO
SSO 在服务器设置中为整套部署配置，而不是按工作区配置。完整说明请见帮助中心的单点登录页面，下面是精简版。
1. 在身份提供商处注册 MonoChat
创建一个带有 client secret 的 Web 应用，并为其设置：
- 重定向 URI
https://<your MonoChat domain>/api/oauth/oidc/redirect； - 授权码模式（authorization code grant）；
- scope 为
openid email profile； - 客户端认证方式为把密钥以 HTTP Basic 发送（
client_secret_basic）。
请确保 ID 令牌包含 email 声明，并记下 client ID、client secret 和 issuer。
2. 原样复制 issuer
issuer 就是您的提供商发现文档中的 issuer 值。常见格式如下：
| 身份提供商 | Issuer |
|---|---|
| Microsoft Entra ID | https://login.microsoftonline.com/<tenant id>/v2.0 |
| Okta | https://<your Okta domain>/oauth2/default 或 https://<your Okta domain> |
| Keycloak | https://<your Keycloak host>/realms/<realm> |
| AD FS 2016 及以上版本 | https://<your AD FS host>/adfs |
| Google Workspace | https://accounts.google.com |
请在浏览器中打开 <issuer>/.well-known/openid-configuration，逐字符复制该值，如果末尾有斜杠也要一并复制。两者只要有差异，MonoChat 就会拒绝所有登录，这是首次测试失败最常见的原因。
3. 添加设置并重启
公开部分（issuer、client ID、重定向路径、scope 和按钮文字）放在 public.oauth.oidc 下；client secret 放在 oauth.oidc 下，只保留在服务器上。其中有两个选项承载着上面表格里的决策：
autoCreateAccounts: true会在某人首次 SSO 登录时创建 MonoChat 账号，即使注册方式设置为仅限邀请也是如此；allowedEmailDomains: ["yourcompany.com"]会拒绝其他域名下的所有邮箱地址。对于 Google Workspace，MonoChat 检查的是账号所属的 Workspace 域名（hd声明），而不是邮箱地址，因为个人 Google 账号可以使用任意域名的邮箱地址。
按钮上显示的是“使用 SSO 登录”（以每个人所用的语言显示），或者您自己设置的文字，例如“使用 Northwind SSO 登录”。
4. 安全地让 SSO 成为唯一方式
当所有人都关联了 SSO 之后，把允许的登录方式（public.auth.methods）设为 ["oidc"]。此后登录页只显示 SSO 按钮，服务器会拒绝密码登录和社交账号登录。Root 超级用户仍可通过 /auth/signin?fallback=1 用密码登录，因此身份提供商宕机时不会把整套部署锁住。如果要阻止新的 SSO 账号自行创建工作区，请把 public.disableTenantCreation 设为 true。
5. 测试四种登录
- 已有账号的人：弹出窗口关闭，随即进入系统。
- 没有账号的人：账号被创建；如果您没有开启自动创建账号，则被拒绝。
- 来自其他域名的人：如果您限制了域名，则被拒绝。
- 在仅限 SSO 的状态下用密码登录：被拒绝，而 root 后备登录仍然可用。
已有的客服：账号是如何关联的
大多数团队开启 SSO 时，客服已经有了 MonoChat 账号。MonoChat 会用以下两种方式之一，把 SSO 关联到邮箱地址相同的已有账号：
- 自动关联：在首次 SSO 登录时，如果部署允许合并，并且 ID 令牌表明该邮箱地址已验证（
email_verified: true）。 - 一次密码登录之后：其他所有情况下，MonoChat 会请此人先用密码登录一次，然后在那时关联 SSO。接受工作区的邀请同样会完成关联。
Microsoft Entra ID 和 AD FS 不会发送 email_verified。使用它们时，在切换为仅限 SSO 之前，请继续允许密码登录，直到所有人都关联了 SSO，或者重新邀请这些人。
SSO 是身份，角色才是访问权限
登录让一个人拥有账号，而不是拥有访问您会话的权限。一个 MonoChat 账号可以属于多个工作区，人们是先登录、再选择工作区。只有在工作区邀请了某人并为其分配角色之后，此人才能看到该工作区，角色决定他能接触哪些渠道、会话和设置。如何设置角色，请参阅团队收件箱角色与权限。
这种分工正是审计人员希望看到的：
- 入职： 由身份提供商创建此人；工作区管理员邀请他并选择角色。
- 调岗： 在 MonoChat 中更改角色或工作组，登录方式不变。
- 离职： 在身份提供商处停用此人，并在 MonoChat 中把他从工作区移除。
需要提前规划的限制
- 移动应用。 MonoChat 的 Android 和 iOS 应用目前还不提供 SSO。如果 SSO 是唯一的登录方式，客服就无法在手机上登录，因此请为移动端用户保留另一种方式，或者把班次安排在电脑端。
- 退出登录。 退出 MonoChat 不会让此人退出身份提供商，目前在身份提供商处退出也不会让他退出 MonoChat。在身份提供商处停用离职员工，可以阻止新的登录；同时也请把他从工作区中移除。
- 网络。 用户的浏览器必须能访问
/api/oauth/oidc/authorize和重定向路径，MonoChat 服务器必须能通过 HTTPS 访问您的提供商的发现文档、令牌端点和密钥集。如果您还按 IP 限制了这套部署的访问，请留意这些路径。
SSO 在 MonoChat 中的位置
SSO 在整套部署的服务器设置中配置，因此目前它属于本地部署的 MonoChat：这是企业版的一种选择，面向在自有服务器上运行平台、并使用自己的 LLM 和向量数据库的团队。企业版页面介绍了本地部署方案，安全页面则涵盖了基于角色的访问控制、工作区隔离和认证。关于 AI 上线中的数据问题，请参阅 AI 聊天机器人数据隐私清单。
如果想先体验产品本身，可以在 app.monochat.ai 使用免费的 Basic 套餐，它包含一名客服和一个渠道。
参考来源
- OpenID Connect Core 1.0，OpenID Foundation，2026 年 11 月 4 日访问
- Verizon 2025 年数据泄露调查报告发布公告，2026 年 11 月 4 日访问
- MonoChat 帮助中心：本地部署的单点登录，2026 年 11 月 4 日访问
- MonoChat 更新日志 3.8.43，2026 年 11 月 2 日
用 MonoChat 付诸实践