2025-07-15

DB / mysql

6 分钟读完 (大约 841 个字) 0次访问

250715-开放平台用户身份认证对接方案

🏢 开放平台用户身份认证对接方案

🏢 开放平台用户身份认证对接方案

版本：v1.0
发布日期：2025年8月
适用对象：内部研发团队、合作方系统服务商

一、方案背景

为保障用户数据安全、统一接入标准、支持多服务商快速集成，特制定本《开放平台用户身份认证对接方案》，采用 AppID + AppKey + Ticket票据机制 实现安全、可扩展的身份传递体系。

二、目标与原则

✅ 核心目标

安全传递用户身份信息，不暴露原始登录态（如 session、token）
支持多个合作方系统接入，具备平台化扩展能力
提供标准化接口与文档，降低对接成本
防止重放攻击、伪造请求、信息泄露

🔐 设计原则

原则	说明
安全性	所有敏感操作需签名验证，Ticket一次性使用
解耦性	合作方无需理解SaaS内部认证逻辑
可控性	掌握用户信息发放主动权
可审计	所有调用记录日志，支持追溯

三、系统角色

角色	说明
用户	使用微信小程序的业主或住户
小程序	前端载体，集成SaaS主功能与合作方H5页面
SaaS平台	主系统，负责用户管理、认证、Ticket签发
合作方系统	外部服务商系统，需获取当前用户信息
开放平台管理后台	合作方应用注册与配置中心

四、整体流程图

开放平台认证流程

五、关键机制设计

1. 第三方应用注册

在 开放平台管理后台 为每个第三方系统分配：

字段	示例	说明
`AppID`	`third_repair_01`	全局唯一标识
`AppKey`	`a1b2c3d4e5f6...`	密钥，仅SaaS保存，用于签名
回调域名	`https://repair.example.com`	白名单校验，防止非法调用
状态	启用/禁用	可动态控制接入权限

⚠️ AppKey 不得在前端或URL中传输，仅用于后端签名。

2. Ticket票据机制

特性	说明
类型	UUID格式，如 `tk_7a8b9c0d1e2f`
存储	Redis缓存，Key: `ticket:<ticket_value>`
内容	JSON结构：`{user_id, openid, phone, community_id, app_id, expire_at}`
有效期	默认 180 秒（可配置）
使用策略	一次性使用，获取后立即删除或标记为已用

3. 请求签名机制（Sign）

第三方调用开放API时必须携带签名，防止伪造请求。

签名算法：

sign = HMAC-SHA256(
    app_id + '&' +
    ticket + '&' +
    timestamp,
    appKey
).toHex().toLowerCase()

参数说明：

参数	是否必填	示例	说明
app_id	是	third_repair_01	第三方系统ID
ticket	是	tk_7a8b9c0d1e2f	从小程序获取
timestamp	是	1712345678	Unix时间戳，精确到秒
sign	是	e3b0c44…	签名值

六、接口定义

1. 获取 Ticket（SaaS内部接口）

小程序端调用，需用户已登录

1
2
3

POST /api/v1/auth/ticket
Authorization: Bearer <user_token>
Content-Type: application/json

请求体：

{
“app_id”: “third_repair_01”
}

响应成功：

{
  "code": 0,
  "msg": "success",
  "data": {
    "ticket": "tk_7a8b9c0d1e2f",
    "expire_in": 180
  }
}

2. 获取用户信息（开放API）

# mysql

文章

161

分类

标签

关注我