随着企业数字化系统持续扩建，多数公司会陆续上线 CRM 客户管理、ERP 生产系统、小程序后端、MES 车间管理、OA 办公平台多套业务系统。

  早期单体项目依靠 Session 完成登录校验，系统数量少的时候可以稳定运行；当业务拆分为多个ASP.NET Core 独立服务之后，登录状态不互通、账号重复维护、权限无法统一管控等问题集中暴露。 很多开发团队选择简单粗暴的数据库账号表共享方式临时解决登录问题，但该方案存在权限隔离差、无法管控会话、扩展性弱等缺陷，难以支撑长期迭代。   本文基于.NET 技术栈，讲解分布式场景下统一身份认证中心完整落地思路，包含架构设计、令牌流转、鉴权逻辑、集群部署以及线上高频故障解决方案。

一、传统单体身份方案迁移分布式面临四大痛点

1、Session 无法跨服务共享

Session 依托服务器本地内存，多实例、多服务部署时，用户登录请求落在不同节点，频繁出现重复登录。使用 Redis 共享 Session 仅适合小型项目，微服务数量增多后权限管理难以标准化。

2、多系统独立账号，运维成本高

每套业务系统独立维护账号、角色、菜单权限，新增员工需要在多个后台逐一创建账号；员工岗位变动，权限同步流程繁琐，极易出现权限遗漏或者权限越权风险。

3、内外网终端难以统一接入

内部管理后台、外部小程序、客户 H5 页面需要不同登录方式，传统方案无法统一管理登录渠道，缺少登录来源校验、设备风控能力。

4、缺少标准化鉴权规范

各个开发人员自定义登录校验逻辑，有的基于 Cookie、有的自定义 Token，代码标准不统一，新人维护难度大。

二、主流三种分布式身份方案选型对比

选型结论：中长期数字化项目、制造业、政企私有化定制系统，优先搭建独立统一认证中心；短期小型内部系统，可以临时采用共享账号表过渡

三、基于ASP.NET Core 统一认证中心标准架构设计

整套架构分为三大模块，职责完全解耦：

1. 认证中心（Identity 服务）

✅唯一负责：账号密码校验、短信登录、令牌生成、RefreshToken 持久化、用户会话管理、主动踢人下线。 

✅支持多种登录方式：账号密码登录、验证码登录、小程序一键授权登录。 

✅签发标准 JWT 令牌，包含用户 ID、角色标识、权限 Scope、过期时间。

2. 业务应用服务（ERP/CRM/MES 等）

不连接账号数据库，不处理登录逻辑。收到请求后，解析 JWT 令牌、校验签名有效性，判断用户权限，放行或者拒绝访问。 

关键点：业务服务只验签，不向认证中心远程请求校验，降低跨服务调用压力。

3. 公共支撑层

✅Redis 缓存：存储黑名单 Token（主动下线用户）、频繁登录限流； 

✅数据库：保存账号信息、角色、菜单权限、客户端应用配置； 

✅日志模块：记录登录日志、异常鉴权记录，满足审计需求。

四、核心技术落地关键细节（工程实战重点）

4.1 JWT 令牌设计规范

✅AccessToken：短期有效（30~60 分钟），用于接口鉴权；

✅RefreshToken：长期有效，持久化存入数据库，AccessToken 过期后，使用刷新令牌换取新凭证；

✅禁止在 Payload 存放敏感数据（手机号、密码），仅存放身份标识与权限编码；

✅生产环境必须使用非对称加密 RSA 签名，杜绝使用 HS256 对称密钥，防止密钥泄露引发伪造令牌风险。

4.2 跨服务权限控制两种模式

✅基于角色鉴权：适合简单系统，判断用户所属角色；

✅基于资源 Scope 鉴权：精细化管控接口，不同业务系统分配独立权限范围，防止越权访问。

4.3 集群部署必须解决的问题

✅多实例部署认证中心，RSA 公钥私钥统一配置，不能动态生成；

✅Redis 使用分布式部署，保证黑名单、登录限流数据全局同步；

✅刷新 Token 接口增加并发控制，避免前端重复请求生成多组令牌。

五、项目上线极易出现的典型故障与解决方案

• 现象：服务重启后，所有已登录用户被迫下线

  原因：代码内动态生成 RSA 密钥；解决方案：密钥文件配置到服务器，所有实例共用同一套公私钥。
  

• 现象：令牌未过期，但是用户被强制退出

  原因：用户主动下线未加入黑名单；解决方案：搭建 Redis 黑名单机制，校验 Token 时优先匹配黑名单。

• 现象：小程序、H5 登录成功，后端接口持续 401 未授权

  原因：跨域、前端请求 Header 名称不统一、令牌携带多余空格；统一 Authorization 请求头格式。

• 现象：RefreshToken 频繁失效

  原因：未做会话唯一性控制；可配置：刷新令牌之后旧 RefreshToken 立即失效。

• 现象：权限越权，切换账号依旧能访问原有数据

  原因：仅校验接口权限，未校验数据权限；架构层面区分「接口权限」和「行级数据权限」。

六、实施落地标准流程

1、需求梳理：统计现有业务系统数量、终端类型（后台 / 小程序 / H5）、登录方式；

2、搭建独立ASP.NET Core 认证中心，配置 RSA 加密、数据库、Redis；

3、定义统一令牌格式、权限编码规范；

4、在各个业务服务集成 JWT 校验中间件；

5、账号数据迁移，实现新旧登录方案兼容；

6、灰度切换登录体系，保留过渡期双登录模式；

7、全面测试：异常登录、过期令牌、主动下线、多端同时在线场景；

8、正式切换，下线老旧登录逻辑。

七、总结

  很多开发团队在项目初期优先实现业务功能，将身份认证简单处理，等到多系统并存之后重构登录体系，改造工作量巨大。 统一身份认证中心不只是解决 “单点登录”，更是企业数字化系统权限体系的底座。基于ASP.NET Core + JWT + OIDC 搭建认证平台，能够适配后续持续新增业务系统、移动端应用，支撑企业未来 3~5 年数字化扩张，避免重复开发登录模块。

  我司深耕.NET 技术栈开发，擅长分布式系统架构、微服务改造、统一身份认证平台、企业管理系统定制开发，具备 ERP、MES、小程序一体化项目落地经验，支持源码交付、私有化部署，可提供架构方案评估与定制开发服务。