统一认证工具如何统一账号认证

本文目录导读：

1. 建立统一的身份数据源
2. 建立集中认证中心
3. 通过协议实现“一次登录，到处访问”
4. 定义统一的权限与角色（授权）
5. 常见的统一认证工具/方案
6. 总结：实现了什么？

统一认证工具（通常指单点登录系统，如OAuth 2.0、SAML、CAS、LDAP等）实现账号认证统一的核心理念是：将“认证”和“授权”从各个应用中剥离出来，集中到一个独立的认证中心。

不是让你在每个系统都输一次密码,而是认证中心判断你是否已登录，然后告诉各个应用“这个人可信”。

以下是实现统一账号认证的四个核心步骤和原理：

建立统一的身份数据源

这是基础,所有系统不再各自维护一份用户密码表，而是共享一个权威的用户信息库。

• 集中存储： 使用LDAP（如OpenLDAP/Active Directory）或关系数据库（如MySQL/PostgreSQL）作为唯一的用户数据库。
• 统一标识： 每个用户拥有一个全局唯一的ID（如工号、手机号、邮箱），所有子系统只存储这个ID，不存密码。
• 密码策略统一： 所有密码复杂度、过期时间、重置流程都由认证中心统一管理。

建立集中认证中心

所有登录请求都发送到这个“中央大门”，而不是各个应用的后台。

• 登录入口： 用户访问任意一个子应用（如OA），系统发现未登录，自动重定向到认证中心的登录页面。
• 凭据验证： 用户在认证中心输入账号密码、验证码或进行生物识别（指纹/人脸）。
• 生成“通行证”： 验证通过后，认证中心生成一个加密的Token（如JWT令牌）或Session/Cookie，作为用户已登录的证明。

通过协议实现“一次登录，到处访问”

这就是统一认证的核心机制,目前主流有OAuth 2.0 / OIDC和SAML两种协议。

以最常见的OAuth 2.0流程（授权码模式）为例：

1. 用户首次访问应用A：
   • 用户访问OA系统,OA发现请求中没有有效凭证，将用户重定向到认证中心。
2. 请求登录：

   用户在认证中心输入账号密码,认证中心验证通过。

3. 发放授权码：
   • 认证中心生成一个临时的授权码，并重定向回OA系统。
4. 兑换令牌：
   • OA系统拿着这个授权码,在服务器端（不经过浏览器）直接去认证中心换取Access Token（访问令牌）和ID Token（身份令牌）。
5. 获取用户信息：

   OA系统拿到Token后,可以解析其中的用户ID或向认证中心的用户信息接口查询用户基本资料（姓名、部门、角色等）。

6. 用户访问应用B（单点登录生效）：
   • 用户在不关闭浏览器的情况下,点击链接进入财务系统B。
   • 财务系统B发现未登录,也重定向到认证中心。
   • 关键步骤： 认证中心检查用户浏览器上的全局Session，发现用户已经登录过，于是不再要求输入密码，直接生成一个新的授权码，重定向回系统B。
   • 系统B用授权码换取Token,完成登录。整个过程用户无感。

定义统一的权限与角色（授权）

统一认证不止管登录,通常也管“能干什么”。

• 角色（Role）： 在认证中心定义“管理员”、“普通员工”、“审计员”等角色。
• 权限（Permission）： 将“添加用户”、“删除订单”等动作与角色绑定。
• 统一下发： 当用户登录OA系统时，认证中心不仅告诉OA“这个人是谁”，还会发送一个加密的Token，其中包含 roles: [‘admin’] 等字段，OA系统根据这个字段决定显示哪些菜单或按钮。

常见的统一认证工具/方案

实现了什么？

• 用户体验： 一次登录，访问所有授权的应用，无需重复输入密码。
• 安全性： 密码只在认证中心一次输入，不会被应用系统截获；支持多因素认证（如密码+手机验证码）；任何应用下线，全局会话失效。
• 运维效率： 员工离职，只需在认证中心一个地方禁用账号，所有应用立即生效，无需到每个系统去操作。

一句话概括：统一认证工具通过一个集中的认证中心，在用户首次登录后生成全局会话，后续访问任何关联系统时，通过协议（如OAuth）自动验证这个会话，从而完成“一次认证，到处通行”。

标签： 单点登录