使用OpenID Connect的Web应用本地开发环境搭建相关问题咨询

针对你提出的四个问题，给出可直接落地的实操方案如下：

• **是否需要单独搭建本地OpenID Provider（OP）实现本地登录？
  不需要从头搭建复杂服务，可根据你的需求选轻量化方案即可：
  1. 配置成本最低的方案是用容器运行轻量化的mock OP工具，比如oidc-server-mock，只需要简单配置测试用户、允许http://localhost:8000之类的本地回调地址，10分钟内就能跑通完整登录流程；
  2. 如果你们的测试环境OP允许添加localhost回调，也可以直接给每个开发者申请单独的测试客户端，不用本地搭OP，直接对接测试环境的OP即可。
• **CI 上的集成测试如何处理身份验证逻辑？
  分场景处理即可：
  1. 普通业务集成测试：直接mock OIDC 校验环节，硬编码返回固定格式的测试用户身份信息，跳过真实的OIDC交互流程，提升测试运行效率；
  2. 全链路E2E测试：在CI任务里临时启动一个轻量化mock OP容器，预配置测试客户端和测试账号，走完整的真实登录流程，不需要依赖外部服务，避免CI任务因外部服务不稳定失败。
• **本地开发降级使用第二种身份验证方式是否违反12 factor的环境一致性原则？
  只要做好抽象就不会违反核心要求：
  建议你先把身份验证逻辑抽象成统一的接口，本地用的第二种验证方式和生产用的OIDC验证方式都实现同一个接口，上层的用户信息解析、权限校验逻辑完全复用，仅身份来源的差异只有最底层的身份获取环节，和生产环境的逻辑差异极小，不会出现本地跑通生产出问题的情况。只有你直接换一套完全独立的身份体系才会违反一致性原则。
• **非生产环境是否可以完全stub身份验证逻辑？
  可以分环境灵活处理：
  1. 给测试、产品使用的测试环境建议保留完整的OIDC流程，方便排查登录相关的真实场景问题，避免上线才发现登录bug；
  2. 本地开发、CI自动化测试场景可以完全stub身份验证逻辑，只要保证stub返回的用户信息结构和真实OP返回的结构完全一致即可，既可以大幅提升开发和测试效率，也不会影响业务逻辑的正确性。

注意stub的时候不要跳过权限校验逻辑，只需固定返回测试用户的身份信息，避免本地开发时漏测权限相关的问题。

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