如何使用Client ID与Secret实现API调用方身份认证

首先明确两者的基础定位：

• Client ID是应用的公开唯一标识符，可对外暴露，作用是让服务端快速识别请求对应的应用身份，你之前调用Azure AD接口传入Client ID就是这个用途
• Client Secret是仅应用方和授权服务方知晓的私密凭证，严禁对外泄露，它的使用逻辑既可以和Client ID配对作为类用户名/密码的组合参与身份校验，也可以作为密钥生成哈希签名参与校验，但不会用于加密整个调用请求，具体分两种常见场景：
  1. 直接配对校验：一般出现在服务端到服务端的OAuth2 Client Credentials令牌申请流程，会将Client ID和Secret放在HTTPS请求的授权头或请求体中传给授权服务，服务端匹配两者的对应关系即可完成身份校验，因为走HTTPS加密传输，不会出现明文泄露的问题
  2. 哈希签名校验：不需要把Secret直接在网络中传输，请求方用Secret作为密钥，对请求参数、时间戳、随机串等内容生成哈希签名，服务端收到请求后用存储的同一份Secret按相同规则生成签名，对比一致即可判定请求合法，安全性更高，可防止重放、篡改攻击

你要做跨服务无session的身份认证，推荐优先用标准化的OAuth2 Client Credentials流程，实现成本低且安全规范，具体落地步骤如下：

1. 凭证存储与管理 #

• 搭建应用注册能力，给每个接入的微服务分配唯一Client ID，以及长度不低于32位的随机高复杂度Client Secret，Secret仅在首次生成时展示给接入方，不做二次返回
• 服务端存储Secret时必须用bcrypt、Argon2等单向哈希算法加盐存储，避免数据库泄露导致Secret批量外泄
• 支持Secret定期轮转能力，更换时旧Secret可设置7天过渡期，避免业务中断

2. 令牌颁发接口实现 #

• 开发令牌颁发接口POST /api/oauth2/token，要求请求方通过Basic Auth传递凭证：将ClientID:ClientSecret做Base64编码后放到请求头Authorization: Basic <编码内容>中，同时请求体携带grant_type=client_credentials固定参数
• 接口逻辑：解码请求头拿到Client ID和明文Secret，查询数据库对应Client ID的哈希Secret，校验传入的Secret与哈希值是否匹配，匹配通过则生成JWT格式的Access Token，有效期设置1~2小时即可，无需下发Refresh Token
• 给接口加请求频率限制，避免暴力破解凭证

3. 业务接口校验逻辑 #

• 所有业务接口校验请求头的Authorization: Bearer <Access Token>，直接验证JWT的签名、有效期即可完成身份校验，全程不需要存储session，完全无状态
• 可在JWT的Payload中存入应用权限标识，同时完成接口权限校验

4. 强制安全规则 #

• 所有内部接口必须走HTTPS传输，禁止HTTP暴露
• 严禁任何场景将Client Secret下发到前端、客户端等不可信环境

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