SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场cometchat-security

cometchat-security

安全与审计

查看项目

更新于 10-21 20:29

技能介绍

用途

本技能用于把 CometChat 集成带入企业安全审查场景：与自有 IdP 的 SSO、基于角色的权限、会话撤销、多租户隔离，或整体“让聊天安全/合规到可上线”。客户端登录接线本身属于 cometchat-<family>-core / -production，本技能负责它们所依赖的服务端与访问控制模型。

认证模型（先搞清这一点）

三种凭据、三个归属地，混淆它们是头号安全缺陷：

  • Auth Key：由客户端持有，仅限开发环境。用于开发中的 quick login(uid)，可为任意用户铸造会话——绝不可上线。
  • Auth token：由客户端按用户持有。生产环境用每用户令牌登录，调用按框架区分（web/Angular/Android/Flutter 用 loginWithAuthToken(token)，iOS 用 login(authToken:)，React Native 用 login({ authToken })）；绑定单个 UID，可撤销。
  • REST API Key：仅服务端持有。用于铸造令牌、管理用户/角色，拥有全部权限——绝不可放入客户端。

生产登录始终使用 auth token，绝不使用 Auth Key。各框架客户端调用的细节见 cometchat-<family>-production。

SSO / OIDC / SAML——通过你自己的 IdP

CometChat 依附于你已有的身份体系。无论 IdP 是 Okta、Auth0、Cognito、Entra ID、Google Workspace 还是自建，流程一致：

  1. 用户通过你的 IdP（SAML/OIDC）登录——即你正常的应用认证。
  2. 你的后端在该已认证会话上，把 IdP subject 映射为 CometChat UID（稳定、经清洗的 id——见 cometchat-migrate-from-* 的 toCometChatId，规则为字母数字加连字符、≤100、小写），若用户为新用户则创建（POST {DOCS_BASE}/rest-api/users，withAuthToken: true 可在同一次调用中返回令牌）。
  3. 你的后端铸造 auth token：POST /v3/users/{uid}/auth_tokens，携带 REST API Key（{DOCS_BASE}/rest-api/auth-tokens/create）。
  4. 通过已认证请求把令牌返回客户端；客户端用其按框架调用登录（web/Angular/Android/Flutter 用 loginWithAuthToken(token)，iOS 用 login(authToken:)，React Native 用 login({ authToken })——见 cometchat-<family>-production）。

UID 必须来自服务端会话，绝不能来自请求参数。接受 ?uid= 会让任何调用者冒充任何人——这是 CometChat 最常见的认证漏洞。

POST https://{APP_ID}.api-{REGION}.cometchat.io/v3/users/{uid}/auth_tokens
apikey: {REST_API_KEY}          # server-side secret
content-type: application/json

会话控制与撤销

Auth token 默认不过期，CometChat 为每个用户保留滚动 100 个（最旧的自动归档）。企业级会话控制：

  • 登出单个设备 → DELETE /v3/users/{uid}/auth_tokens/{authToken}。
  • 终止全部会话（员工离职、疑似失陷）→ DELETE /v3/users/{uid}/auth_tokens（全部清空）。
  • 权限变更/密码重置时轮换 → 铸造新令牌，清空其余。
  • 短会话 → 每次登录签发一个令牌，登出时清空；不要长期复用一个令牌。

页面：{DOCS_BASE}/rest-api/auth-tokens/{delete,flush}。

访问控制——RBAC（应用级）+ SBAC（群组级）

CometChat 有两层；一个操作必须同时通过两层，否则 API 返回 ERR_PERMISSION_DENIED：

  • Role（RBAC）：作用域为整个应用，每用户一个角色，通过用户创建/更新（/rest-api/users）、roles（/rest-api/roles）设置，用于控制谁可以创建群组、发消息、发起通话等。
  • Scope（SBAC）：作用域为单个群组内，通过群组成员（/rest-api/group-members/change-scope）设置，用于群组内的 admin / moderator / participant。

通过 REST Roles 端点（POST https://{APP_ID}.api-{REGION}.cometchat.io/v3/roles；见 {DOCS_BASE}/rest-api/roles）在服务端定义角色——每个用户恰好一个；未指定则为默认。

通过 RBAC（{DOCS_BASE}/rest-api/rbac-overview）为每个角色设置细粒度权限。（旧的按角色 restrict-features API 已弃用——请使用 RBAC。）

群组 scope（admin/moderator/participant）是 SBAC 层；用 change-scope API 修改。按最小权限建模：默认角色收紧，为员工/管理员设置更高角色，再加群组 scope 做群内管理。

多租户隔离

  • 最强：每个租户一个 CometChat 应用（独立 App ID/密钥——完全数据隔离）。适合受监管或合同要求隔离的场景。
  • 较轻：单应用，租户范围的群组 + 用户/消息元数据中的租户 id，由你的令牌服务器强制（用户只会拿到其租户 UID 的令牌）+ RBAC。成本更低，但隔离强度取决于你的服务端校验。

按合规标准选择；记录你选了哪种。数据驻留/区域选择见 cometchat-compliance；完全主权的自托管见 cometchat-self-host。

常见陷阱

  • 生产环境把 Auth Key 发到客户端——它能以任何人身份登录。检查 bundle/二进制（cometchat-<family>-production）。
  • 令牌端点信任客户端提供的 UID——可被冒充。UID 必须从服务端会话推导。
  • 把“CometChat SSO”误读为 CometChat 是 IdP——它不是；应集成你的 IdP，再铸造令牌。
  • 离职时未撤销——被停用的用户仍能聊天，直到你清空其令牌。
  • 假设有 RBAC 却从未配置——所有用户都停在默认角色；需显式定义角色与权限。
  • 使用已弃用的 restrict-features 而非 RBAC。
  • REST API Key 出现在客户端或仓库——仅限服务端；存入密钥管理器。

验证是否生效

IdP 登录 → 服务端从会话 UID 铸造令牌 → 客户端按框架的 auth-token 登录成功（loginWithAuthToken / iOS login(authToken:) / RN login({ authToken })）· 被篡改的 ?uid= 请求被拒绝 · 清空某用户令牌后其所有设备会话结束 · 默认角色用户被拒绝受限操作（ERR_PERMISSION_DENIED）而更高角色被允许 · 客户端代码中不存在任何 Auth Key 或 REST API Key。