安全实践
凭证保护、Token 安全与集成方安全建议。
凭证存储
| 凭证 | 性质 | 保管建议 |
|---|---|---|
client_id | 公开标识 | 可在集成方应用中使用 |
client_secret | 长期机密 | 妥善保管，避免随源码 / 应用包体 / 前端代码 / 日志外泄 |
code_verifier | 一次性 | 授权流程内使用，用完即弃 |
access_token | 短期凭证（1 小时） | 限定调用方持有，不建议在多端之间传播 |
refresh_token | 长期凭证（永久有效） | 与 client_secret 同等强度保管 |
ℹ️
上表只描述凭证的安全等级，具体存储位置（应用进程内存 / Keychain / 自有密管系统等）由集成方按自身架构决定。
webview token 安全
- 一次性签发 — 调用 获取内嵌页 URL 接口每次返回新 token
- 可重放 — 在服务端规定的有效期内可被多次使用（WebView 内多次刷新页面、调用接口都用同一 token），不绑定 IP / UA（否则移动设备切网会失败）
- 泄露风险 — URL 中的 token 可能出现在浏览器历史、Referer header、应用日志
- 最佳实践 — 临用临换，不要把 webview URL 长期缓存
⚠️
避免把内嵌页 URL 写入持久化日志，防止 token 泄露后被重放利用。
state 参数与 CSRF 防护
为防 CSRF，建议：
- 每次发起授权前生成新的
state（≥ 32 字节随机串） - 与 PKCE
code_verifier一同绑定到当前会话 - 回调返回时，校验
state与本地一致后再进入换 token 流程
指定 Space 模式安全说明
| 风险 | 处理方式 |
|---|---|
space_id 在授权 URL 中被中间人篡改 | 服务端在 GET /openapi/v1/oauth/auth 阶段将 space_id 锁入 session；Consent 页只持有 session_token，无法修改绑定的 Space |
| 恶意方伪造授权 URL 向任意 Space 塞入成员 | 预添加成员接口需要有效 Bearer Token，且 App 必须有权操作目标 Space；未授权 App 无法调用 |
| 未预添加的用户尝试通过 OAuth 授权进入 Space | 服务端校验成员是否存在，不存在则返回 access_denied，不会自动创建成员 |