如何搭建独立REST API为多个应用提供统一身份认证服务

1. 业务API能否调用中央认证API完成身份校验 #

该方案完全可行，属于可快速落地的过渡方案，优劣势如下：

• 优势：改造成本极低，不需要调整现有业务API的认证逻辑框架，仅需要将原本本地校验token的逻辑，替换为向中央认证API发起token合法性校验请求即可；用户数据完全收敛在中央认证服务存储，不会出现多服务数据不一致问题。
• 劣势：会产生额外的跨服务网络IO开销，所有需要认证的业务接口都会多一次调用请求，高并发场景下会明显拖慢业务响应速度；同时中央认证API的可用性会直接影响所有业务API的可用性，存在单点故障风险。

2. 行业最佳实践 #

针对多服务统一身份认证的场景，优先推荐以下落地方案：

• 首选无状态JWT认证方案替代集中式校验逻辑
  由中央认证服务统一负责用户登录校验、签发带签名的JWT Token，JWT载荷中可携带用户ID、权限范围、有效期等可公开的身份信息。所有业务API本地通过预设的签名公钥/密钥即可完成Token合法性校验，不需要跨服务调用中央认证服务，彻底消除额外网络开销，规避单点故障风险。
  Django生态可直接使用djangorestframework-simplejwt库实现JWT的签发与校验，仅需要所有业务API和中央认证服务共用同一套签名密钥即可，不需要同步用户数据库。如果需要支持Token即时吊销，可由中央认证服务维护JWT黑名单，业务API校验签名后仅需查询本地缓存的黑名单列表即可，无需实时调用中央服务。
• 高复杂度权限场景补充本地缓存+异步更新机制
  如果业务API需要用到的用户权限、角色属性较多，无法全部放入JWT载荷，可在业务API首次校验用户Token合法后，将用户的权限信息缓存到本地Redis，设置合理的过期时间，缓存过期后再异步向中央认证服务拉取最新权限数据，兼顾性能与数据一致性。
• 强合规场景保留集中式校验时增加熔断降级策略
  如果业务有强合规要求，必须实时校验Token有效性，可保留业务API调用中央认证API的逻辑，但必须添加熔断、降级策略：给校验请求设置短超时，当中央认证服务不可用时，允许业务API基于本地最近N小时的校验缓存放行正常请求，避免整体服务雪崩。

内容的提问来源于stack exchange，提问作者Ruben Adriaanse