基于Microsoft.AspNetCore.Identity的多应用SSO实现方案咨询

前提说明 #

当前两个应用均为.NET Core技术栈，应用A已完成Microsoft.AspNetCore.Identity体系搭建，用户使用邮箱作为账号，以下两种方案均可直接复用现有用户体系，无需重构用户数据层。

方案一：基于OpenID Connect 自建身份认证中心（推荐，支持跨域名、可扩展） #

该方案为行业标准实现，后续新增业务应用可直接接入，不需要重复开发认证模块。

• 改造应用A为身份认证服务端：
  • 引入适配.NET Core版本的IdentityServer4组件（VS2019支持范围最高到.NET 6，选择对应匹配的组件版本即可），直接对接现有AspNetCore.Identity的用户表作为身份数据源，原有邮箱登录逻辑完全复用
  • 在身份服务配置中添加应用B为受信任客户端，配置授权类型为授权码流、允许的回调地址、生效范围等参数
  • 原有应用A的登录页面、密码校验、邮箱验证逻辑无需修改，用户登录感知完全不变
• 改造应用B为认证客户端：
  • 引入Microsoft.AspNetCore.Authentication.OpenIdConnect中间件，配置认证中心地址为应用A的域名，填写之前登记的客户端ID、密钥参数
  • 应用B的受保护接口/页面添加[Authorize]标记，未登录用户访问时自动跳转到应用A的登录页，登录完成后携带有效令牌回调到应用B，校验通过后自动生成本地登录态
• 数据适配：如果需要共享用户扩展信息，两个应用可直接访问同一个SQL库的Identity相关表，不需要做额外数据同步

方案二：共享Cookie认证（轻量场景首选，改造成本极低） #

如果两个应用部署在同一个一级域名下（如a.example.com和b.example.com），用该方案最快可半天内落地。

• 统一两个应用的加密配置：
  • 两边都配置Data Protection服务，使用相同的加密密钥，密钥可存储在两个应用都能访问的共享路径或者SQL数据库中，确保两边可以互相解密对方签发的Cookie
  • 统一配置Cookie的域名为一级域名（如.example.com），两边的认证方案名称、Cookie名称必须完全一致
• 应用A原有登录逻辑完全不需要修改，登录后签发的Cookie可被应用B直接识别
• 应用B仅需添加Cookie认证中间件，校验逻辑和应用A保持一致即可，用户登录应用A后访问应用B，应用B可直接从Cookie的Claims中读取到用户邮箱等身份信息，无需二次登录

落地注意事项 #

• 生产环境必须开启HTTPS，避免Cookie、令牌被窃听，加密密钥需要做好权限管控，禁止明文提交到代码仓库
• 如果两个应用的权限体系独立，可在应用B拿到身份信息后，本地做单独的权限映射，不需要修改应用A的认证逻辑
• 组件安装时注意版本匹配，避免出现.NET Core运行时和第三方组件版本不兼容的问题

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