双系统如何做接口认证-V1

现有A系统，B系统，A系统启动的时候调用B系统的注册接口API1（把A系统配置信息注册到B系统），A系统定时向B系统接口AP2发送心跳信息，B系统根据业务情况，调用A系统的业务接口AP3，请设计两系统的接口认证方式。

针对A系统与B系统间的接口交互需求（注册API1、心跳API2、业务调用API3），设计一套兼顾安全性、可维护性和性能的认证方案如下：

---

​​1. 整体认证架构​​

采用 ​​双向Token+数字签名​​ 的混合认证机制：

• ​​Token机制​​：用于会话状态管理（如心跳保活、业务调用身份标识）
• ​​数字签名​​：基于非对称加密验证请求完整性，防止篡改
• ​​认证流程分离​​：注册接口独立使用高强度认证，心跳与业务接口使用轻量级动态凭证

---

​​2. 接口认证详细设计​​

​​(1) 注册接口 API1​​

A系统启动时调用此接口向B系统注册自身信息。

• ​​认证方式​​：预共享密钥（Pre-shared Key, PSK）或双向TLS
• ​​请求参数​​：

  {"system_id": "A_SYSTEM_ID","public_key": "A_PUBLIC_KEY_PEM",  // A系统的RSA公钥"metadata": "{IP, 端口, 服务列表...}" // 其他配置信息
  }

• ​​安全措施​​：
  • 传输层：强制HTTPS加密
  • 请求签名：使用预分配的密钥生成HMAC签名，B系统验证签名合法性
  • 响应：B系统返回access_token和refresh_token（用于后续API2、API3）

---

​​(2) 心跳接口 API2​​

A系统定时发送心跳证明存活。

• ​​认证方式​​：动态Token + 时间戳签名
• ​​请求参数​​：

  POST /api2?ts=1672531200
  Headers: Authorization: Bearer <access_token>Signature: RSA(<access_token|ts>, A_PRIVATE_KEY)

• ​​安全措施​​：
  • ​​防重放攻击​​：时间戳校验（B系统拒绝超过±30秒的请求）
  • ​​Token有效性​​：B系统验证access_token是否由自己签发且未过期
  • ​​签名验证​​：用A系统的公钥解密签名，比对内容一致性
• ​​心跳超时处理​​：B系统若连续3次未收到心跳，则标记A系统为离线并禁用其access_token

---

​​(3) 业务调用接口 AP3​​

B系统主动调用A系统的业务接口。

• ​​认证方式​​：双向Token验证 + 请求签名
• ​​B系统调用流程​​：
  1. 生成请求唯一ID nonce 和时间戳 ts
  2. 使用B系统的私钥签名：sig = sign(<nonce|ts|payload>, B_PRIVATE_KEY)
  3. 发送请求：

     POST /ap3
     Headers:Authorization: Bearer <B_to_A_token>  // B系统专属TokenX-Nonce: <nonce>X-Timestamp: <ts>X-Signature: <sig>
     Body: <payload>

• ​​A系统验证逻辑​​：
  • 校验B_to_A_token是否有效（由A在注册时颁发给B）
  • 验证nonce未被重复使用（防重放）
  • 用B系统的公钥验证签名

---

​​3. 令牌管理与更新机制​​

​​令牌类型​​	​​用途​​	​​生命周期​​	​​更新方式​​
access_token	API2心跳认证	1小时	定期刷新（API2返回新Token）
refresh_token	刷新access_token	7天	注册时生成，失效后需重新注册
B_to_A_token	B系统调用AP3的凭证	长期有效	A系统在注册时生成并返回给B

• ​​令牌刷新​​：
  A系统在心跳响应中检测access_token临近过期时，主动调用B的刷新接口，使用refresh_token获取新Token
• ​​密钥轮转​​：
  A系统每次重启时生成新密钥对，通过API1更新公钥

---

​​4. 安全加固措施​​

• ​​传输层加密​​：所有接口强制HTTPS（TLS 1.3+）
• ​​IP白名单​​：B系统仅允许预注册的A系统IP调用AP3
• ​​请求限流​​：
  • API2心跳频率限制：每分钟≤1次
  • AP3业务接口：按业务优先级分配配额
• ​​敏感操作审计​​：记录Token生成、刷新、失效日志，便于追踪异常

---

​​5. 容错与异常处理​​

• ​​心跳丢失恢复​​：
  A系统若检测到心跳失败，自动重试3次后触发重新注册流程
• ​​Token失效处理​​：
  • AP3调用返回401 Unauthorized时，B系统需重新申请B_to_A_token
  • A系统收到无效Token时主动清理本地会话状态
• ​​密钥泄露应对​​：
  支持B系统主动吊销A系统的公钥证书，强制A重新注册

---

​​方案优势​​

1. ​​分层认证​​：注册接口独立保障系统级信任，业务接口轻量化认证
2. ​​防篡改与重放​​：数字签名+时间戳+Nonce三重防护
3. ​​动态信任链​​：通过Token生命周期管理和密钥轮转减少长期风险
4. ​​可扩展性​​：支持新增系统（如C系统）通过相同注册流程接入