身份认证（Authentication）

身份认证（Authentication）与授权（Authorization）是信息安全的两大核心支柱，共同构成 “**确认身份合法性→控制资源访问权**” 的全流程安全体系。随着 IT 架构从传统本地环境向云端、分布式、零信任架构演进，这两个领域的技术也从 “静态单一” 向 “动态多维” 升级。

身份认证的核心是 “**确保主体身份的真实性**”，防止未授权主体通过伪造身份访问系统。

其技术体系从 “单一凭证” 发展到 “多维度验证”，从 “本地认证” 升级到 “联邦认证”，可分为**核心技术、认证协议、实践框架**三大模块。

## 概念

| 对比维度     | 身份认证（Authentication）                               | 授权（Authorization）                            |
| ------------ | -------------------------------------------------------- | ------------------------------------------------ |
| **核心目标** | 验证 “**主体是谁**”（确认身份合法性）                    | 决定 “**主体能做什么**”（控制资源访问权限）      |
| **关键问题** | “你是声称的那个人吗？”                                   | “你有访问这个资源 / 执行这个操作的权限吗？”      |
| **执行时机** | 主体首次访问系统、会话过期或触发安全校验时（如异地登录） | 主体通过认证后，每次请求资源或执行操作时         |
| **依赖关系** | 授权的**前提**（未认证则无法授权）                       | 认证的**延伸**（认证通过后才需判断权限）         |
| **通俗比喻** | “刷身份证进入公司大楼”（确认你是公司员工）               | “凭工牌进入研发部办公室”（确认你有研发部访问权） |

## 要素

**主体（Subject）**：发起访问请求的实体，包括用户（个人 / 员工）、应用程序（如第三方 APP）、设备（如 IoT 设备、服务器）；

**资源（Resource）**：被访问的对象，包括数据（如用户信息、财务报表）、功能（如 “删除数据库” 操作）、系统（如 OA、CRM）；

**凭证（Credential）**：认证时用于证明身份的材料（如密码、指纹、令牌）；

**权限（Permission）**：授权时允许主体对资源执行的操作（如 “读取”、“写入”、“删除”、“管理”）。

## 核心技术

> 单因素认证（Single-Factor Authentication, SFA）

定义：仅通过“单一类型的凭证”验证身份，是最传统的认证方式。

类型：

- 知识因子（Something You Know）：用户记忆的信息，如密码、PIN 码、安全问题（“母亲的名字”）；
- 持有因子（Something You Have）：用户拥有的实体 / 设备，如 USB 密钥、硬件令牌（如银行 U 盾）、手机（接收验证码）；
- 生物因子（Something You Are）：用户自身的生物特征，如指纹、人脸、虹膜、声纹。

优点：实现简单、用户体验门槛低。

缺点：安全性弱。

场景：低安全需求场景（如非敏感app、博客等）。

> 多因素认证（Multi-Factor Authentication, MFA）

定义：通过 “两种或以上不同类型的凭证” 组合验证身份，核心逻辑是 “多种凭证同时泄露的概率远低于单一凭证”；

典型组合：

- 知识因子 + 持有因子：“密码 + 手机验证码”（如登录网银时输入密码后接收短信验证码）；
- 知识因子 + 生物因子：“密码 + 指纹识别”（如手机解锁时输入密码 + 按压指纹）；
- 持有因子 + 生物因子：“硬件令牌 + 人脸验证”（如企业高管登录核心系统时使用）。

优势：安全性显著高于SFA。

技术实现：

- 动态口令（TOTP/HOTP）：硬件令牌（如 RSA SecurID）或 APP（如谷歌验证器）生成实时变动的 6 位数字，有效期 30 秒；
- 推送验证：用户发起登录后，手机 APP 推送确认请求（如支付宝的 “刷脸登录确认”）。

场景：中高安全需求场景（如企业 OA、金融 APP、云平台管理后台）。

> 连续认证（Continuous Authentication, CA）

定义：突破 “一次认证终身有效” 的传统模式，在用户访问过程中**持续采集多维度行为数据**（如操作习惯、设备特征），实时验证身份合法性，核心是 “动态判断是否为本人操作”；

数据维度：

- 行为特征：打字速度、鼠标移动轨迹、手势习惯（如手机滑动方向）；
- 设备特征：设备型号、操作系统版本、IP 地址、浏览器指纹；
- 环境特征：地理位置、网络运营商、登录时间（如是否在用户常用时段）。

技术逻辑：通过 AI 模型建立用户 “正常行为基线”，若实时行为偏离基线（如 “用户平时在上海登录，突然在海外登录且打字速度骤变”），则触发二次验证（如 MFA）或阻断访问。

优点：无需用户主动配合，在不影响体验的前提下提升安全性。

场景：高安全需求场景（如金融交易、政府系统、核心数据访问）。

## 协议

当用户需要访问多个关联系统（如企业 OA、CRM、云存储）时，传统 “每个系统单独认证” 的模式效率低 —— 认证协议的核心作用是实现 “**跨系统身份互通**”，支持 “一次认证、多系统通行” 或 “跨平台身份共享”。

> LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）

定义：身份数据存储与查询协议（非直接认证协议，但为认证提供数据支撑）。

作用：集中存储用户身份信息（如账号、密码哈希、部门、邮箱），供认证系统查询验证（如企业 SSO 通过 LDAP 查询用户是否存在、密码是否正确）。

技术特点：

- 采用 “树形目录结构” 存储数据（如 “dc=company,dc=com” 下的 “ou=users” 节点存储所有用户）；
- 支持高效查询（如 “过滤出部门 = 研发的所有用户”），适合企业内部身份集中管理。

场景：企业内部身份数据管理（如微软 AD 域服务基于 LDAP 协议）、传统应用（如邮件系统、VPN）的认证数据来源。

> SAML 2.0（Security Assertion Markup Language，安全断言标记语言）

定位：**企业级跨系统认证协议**（主要用于 SSO 场景）。

原理：通过 XML 格式的 “身份断言（Assertion）” 传递身份信息，包含三个核心角色：

- IdP（Identity Provider，身份提供商）：统一认证中心（如企业 SSO 服务器），负责验证用户身份并生成断言；
- SP（Service Provider，服务提供商）：需要认证的系统（如企业 CRM），接收断言并确认用户身份；
- 主体（User）：发起访问请求的用户。

典型流程：

- 用户访问 SP（CRM），SP 发现未认证，跳转至 IdP；
- 用户在 IdP 输入凭证（如账号密码 + MFA），IdP 验证通过后生成 XML 格式的身份断言（包含用户 ID、部门等信息），并用私钥签名；
- IdP 将断言返回给 SP，SP 用 IdP 的公钥验证断言签名有效性；
- 验证通过后，SP 为用户创建会话，允许访问。

技术特点：安全性高（支持数字签名、加密）、支持复杂身份属性传递（如用户职位、权限等级）。

缺点：基于 XML，解析复杂，不适合移动 APP（XML 在移动端性能差）。

场景：企业级 SSO（如员工通过 IdP 登录 SAP、Oracle 等 ERP 系统）、跨企业认证（如银行与央行监管系统的身份互通）。

> OIDC（OpenID Connect，开放身份连接）

定位：互联网场景的轻量级认证协议，基于 OAuth 2.0 框架扩展（解决 OAuth 2.0“仅授权、无认证” 的缺陷）。

创新：新增 “ID Token”（身份令牌），格式为 JWT（JSON Web Token），包含用户核心身份信息（如用户 ID、昵称、邮箱），由 IdP 签名，SP 可直接解析验证。

核心角色（继承 OAuth 2.0）：

- 资源所有者（User）：用户；
- 客户端（Client）：需要认证的应用（如知乎、抖音 APP）；
- 授权服务器（Authorization Server，即 IdP）：如微信、谷歌的认证中心；
- 资源服务器（Resource Server）：存储用户资源的服务器（如微信存储用户头像的服务器）。

典型流程（基于 OAuth 2.0 授权码模式）：

- 客户端（知乎）跳转至授权服务器（微信），请求认证，参数包含`scope=openid email`（表示需要获取用户 ID 和邮箱）；
- 用户在微信输入凭证并同意授权，微信生成 “授权码”，跳转回知乎；
- 知乎携带授权码向微信请求 “访问令牌（Access Token）” 和 “ID Token”；
- 微信验证授权码有效后，返回 Access Token（用于授权）和 ID Token（用于认证）；
- 知乎解析 ID Token（验证签名、过期时间），获取用户 ID、昵称等身份信息，完成认证。

技术特点：

- 兼容 OAuth 2.0，可同时实现认证与授权；
- 基于 JSON，轻量易解析，适合移动 APP、小程序等互联网场景。

场景：第三方登录（如 “用微信登录知乎”、“用谷歌登录 Gmail”）、互联网企业 SSO（如阿里系淘宝、支付宝、钉钉的统一登录）。

> CAS（Central Authentication Service，中央认证服务）

定位：开源SSO框架（而非协议），基于“票据（Ticket）”机制实现跨系统认证。

组件：

- CAS Server：统一认证中心，负责验证用户身份并发放票据；
- CAS Client：集成在各应用中的客户端组件，负责与 CAS Server 通信。

典型流程：

1. 用户访问应用 A（集成 CAS Client），应用 A 跳转至 CAS Server；
2. 用户在 CAS Server 登录，验证通过后，CAS Server 生成 “服务票据（Service Ticket）”，跳转回应用 A；
3. 应用 A 携带服务票据向 CAS Server 验证有效性，验证通过后允许访问；
4. 用户访问应用 B（同样集成 CAS Client），应用 B 跳转至 CAS Server；CAS Server 检测到用户已登录，生成新的服务票据，应用 B 验证后允许访问。

技术特点：开源免费、部署简单、支持多种身份源（LDAP、数据库、AD）。

缺点：仅支持认证（无授权能力）、功能较单一，逐渐被 OIDC 替代。

场景：小型企业、教育机构内部 SSO（如学校图书馆系统、教务系统的统一登录）。

## 认证中的安全风险

| 安全风险 | 核心风险                                     | 应对措施                                                     |
| -------- | -------------------------------------------- | ------------------------------------------------------------ |
| 凭证泄露 | 密码被破解、MFA 令牌被窃取                   | 1. 密码加盐哈希存储（避免明文）；2. 动态口令有效期缩短（如 30 秒）；3. 禁止凭证明文传输（用 TLS 加密） |
| 钓鱼攻击 | 伪造认证页面骗取用户凭证（如仿冒网银登录页） | 1. 启用 MFA（即使凭证泄露也需二次验证）；2. 浏览器显示官方认证标识（如 EV SSL 证书）；3. 用户安全培训 |
| 会话劫持 | 攻击者窃取认证后的会话 Cookie/Tokens         | 1. 会话 Cookie 设置`HttpOnly`和`Secure`属性；2. Tokens 定期轮换；3. 连续认证检测异常会话 |
| 身份伪造 | 生物特征被复制（如伪造指纹）、设备被冒用     | 1. 采用多模态生物识别（如指纹 + 人脸）；2. 设备绑定（仅允许常用设备认证）；3. 环境校验（如地理位置异常触发二次验证） |