AzureAD：面向外部API系统消费者使用长有效期refresh token的方案问询

1. Refresh Token作为长期密钥存储的合规性 #

该做法完全符合OAuth2规范和AzureAD的安全要求，属于合规的实现方式，落地时需要满足以下安全约束：

• 初始Refresh Token必须由消费者通过自身合法的AzureAD身份（内部员工账号/外部B2B协作账号）走正规授权码流认证后获取，禁止人工分发固定Refresh Token
• 要求消费者将Refresh Token存储在加密的安全配置中心或密钥管理服务中，严禁明文存储在代码仓库、未加密配置文件内
• 在AzureAD中配置Refresh Token的最大有效期，不建议设置为永久有效，可根据业务安全要求设置为3个月到1年，到期后要求消费者重新走身份认证流程续期
• 开启AzureAD的身份保护策略，对异常位置、异常设备的Refresh Token兑换请求自动拦截并吊销对应令牌，降低泄露后的风险。

2. Auth代理API的必要性及替代方案 #

你当前的代理实现逻辑不存在安全问题，是合理的，但你可以选择更简化的原生方案规避自建代理的成本：

你可以将API对应的App Registration设置为公开客户端，配置路径为AzureAD门户→App Registration→对应应用→认证→高级设置→允许公共客户端流，选择「是」即可。
公开客户端本身就是为无法安全存储Client Secret的场景设计的，配置后消费者调用AzureAD令牌兑换接口时，仅需要传入Client ID、授权码/Refresh Token即可，不需要传递Client Secret，完全不需要你额外开发代理层。
如果你的业务要求严格隐藏Client ID，不仅是Client Secret，那自建Auth代理是当前唯一合理的实现方式，只要给代理层加上请求限流、兑换前的Refresh Token合法性校验、调用者权限校验即可，现有PoC逻辑不需要做调整。

现有业务优势的兼容性说明 #

你提到的两个场景优势，不管是用公开客户端方案还是现有代理方案，都完全兼容：

• 内部开发者无需感知任何Client凭证，仅通过自有AzureAD账号、配合安全组绑定的角色即可访问API，管理成本和原有方案一致
• Swagger UI的SSO单点登录能力不受任何影响，可正常使用用户身份完成认证访问。

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