谁应负责OAuth2认证的实施与管理？云服务部署相关咨询

一、OAuth2实施责任的常规划分 #

• 供应商侧责任：
  • 负责实现资源服务器的OAuth2认证校验逻辑，确保只有携带有效OAuth2令牌的请求才能访问其提供的API资源，这是托管API服务的核心安全基础。
  • 若*SDD（软件设计文档）*由供应商编写，即使未明确责任，通常也需提供符合OAuth2规范的资源服务器侧对接能力，包括令牌校验的接口或内置逻辑，以及相关技术文档说明如何与认证系统集成。
  • 保障其托管的云系统及API服务在OAuth2框架下的稳定性、兼容性，比如支持标准的令牌格式（如JWT）、校验算法等。
• 我方责任：
  • 负责认证服务器的搭建、维护与管理，包括用户身份认证、令牌的生成与分发，这部分涉及我方自有用户体系，通常由我方把控。
  • 负责将我方自有API及服务与认证服务器对接，实现获取令牌、携带令牌请求供应商API的逻辑。
  • 若需要自定义OAuth2的扩展逻辑（如特定权限规则），我方需明确需求并协调供应商适配，或自行在认证侧实现。

二、认证服务器与资源服务器的部署常规 #

• 资源服务器：几乎100%部署在供应商提供的托管服务中，因为资源服务器是供应商API服务的一部分，需要与API业务逻辑紧密耦合，由供应商托管才能保障服务的一致性、可用性和运维效率。
• 认证服务器：
  • 常规场景下由我方自行部署（或托管在我方信任的第三方云服务），因为认证服务器涉及我方核心用户数据、身份认证规则，属于我方核心资产，自主管控更安全。
  • 少数情况如果供应商提供成熟的通用认证服务（如SaaS化的身份管理平台），且我方用户体系允许接入，也可以采用供应商托管的认证服务器，但这种情况需要明确数据安全责任边界。
  • 第三方纯托管认证服务器的情况较少，除非我方完全没有身份管理能力，且选择专门的身份认证服务商，但这属于额外的采购范畴，并非此类云系统项目的常规配置。

三、补充建议 #

• 若合同和SDD未明确责任，应尽快与供应商补充签订补充协议，明确双方在OAuth2各组件上的开发、运维、安全责任，避免后续纠纷。
• 技术层面可要求供应商提供资源服务器OAuth2校验的标准对接示例，验证其是否具备规范的对接能力，再推进我方认证侧的开发。

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