认证与授权
安全的本质不是技术堆砌,而是对"信任"的工程化建模。认证与授权,就是在网络世界中构建信任关系的核心机制。
一、安全控制的第一性原理
在计算机安全领域,一切访问控制都可以被抽象为三个最基本的问题:
- **你是谁?** —— 认证(Authentication)
- **你能做什么?** —— 授权(Authorization)
- **你如何证明?** —— 凭证(Credential)
这三者构成了安全体系的最小闭环:
认证 → 生成凭证 → 授权决策无论是:
- HTTP Basic
- CAS
- OAuth
- JWT
- RBAC
本质上都在回答这三个问题,只是解决场景与边界不同。
二、认证的本质
2.1 认证的目标
认证的本质是:
在不可信的网络环境中,建立"主体身份"与"真实个体"的可信映射。
认证并不是单纯的"登录",而是一种信任建立过程。
2.2 认证的基本模式
所有认证方式,都可以归为三类:
| 类别 | 本质 |
|---|---|
| 知识认证 | 你知道什么(密码、密钥) |
| 持有认证 | 你拥有什么(Token、证书) |
| 特征认证 | 你是什么(指纹、人脸) |
三、认证机制的演进路径
认证技术的发展,本质是为了解决三个核心矛盾:
- 用户体验
- 安全性
- 系统复杂度
3.1 本地认证:HTTP 认证
最早的认证发生在单系统场景:
HTTP 协议层提供了标准化的认证框架:
WWW-Authenticate → Authorization流程模型:
客户端 → 服务端:请求资源服务端 → 客户端:需要认证客户端 → 服务端:携带凭证服务端 → 客户端:允许或拒绝这代表的是一种最原始的挑战-响应模型。
3.2 应用层认证:表单认证
由于 HTTP 认证灵活性不足,大部分系统转向了:
表单认证
其本质是:
- 将认证逻辑上移到应用层
- 由业务系统自行控制认证过程
这带来了更大的灵活性,但也意味着:
认证从"协议标准"变成了"工程问题"
3.3 跨系统认证:SSO
当系统从单体走向多系统,新的问题出现:
如何避免用户在多个系统中反复登录?
这催生了一个目标:
SSO —— 单点登录
SSO 的本质不是技术,而是一种目标:
一次认证,多处信任
SSO 的核心思想
统一认证中心 + 分散业务系统- 身份只在一个地方确认
- 结果在多个系统中共享
3.4 SSO 的实现:CAS
CAS 是一种典型的 SSO 实现框架。
其核心机制是:
- Ticket
- 重定向
- 认证中心
三个核心对象:
| 概念 | 本质 |
|---|---|
| TGT | 身份凭证 |
| TGC | 客户端 Cookie |
| ST | 一次性票据 |
CAS 的本质:
用中心化的票据机制,实现跨系统身份传递
3.5 现代化认证:OIDC
当互联网规模进一步扩大,需要跨组织认证时:
- CAS 已不够通用
- 需要标准化协议
于是出现:
OIDC = 认证标准化
OIDC 的本质:
- 在 OAuth2 之上增加"身份认证层"
- 通过 ID Token 标准化身份信息
四、授权的本质
如果说认证解决:
"你是谁"
那么授权解决:
"你能做什么"
4.1 授权的核心模型
授权本质上是一个三元关系:
主体(Subject) ↓权限(Permission) ↓资源(Resource)4.2 授权模型的分类
DAC:自主访问控制
- 由资源所有者决定
- 强调"所有权"
典型代表:Linux 文件权限
本质:
权限属于资源,而非系统
RBAC:基于角色的访问控制
核心思想:
用户 → 角色 → 权限 → 资源RBAC 的本质创新:
用"角色"解耦用户与权限
这是目前企业系统中最常见的模型。
Rule-BAC / ABAC
基于规则或属性的访问控制:
不再只看"你是谁"
还看:
- 时间
- IP
- 行为
- 上下文
本质:
从静态权限走向动态决策
MAC:强制访问控制
强调:
- 安全等级
- 强制策略
常见于高安全领域。
五、凭证:认证与授权的载体
认证和授权的结果,需要一种载体来传递:
这就是凭证(Credential)
5.1 Cookie-Session 模型
最经典的状态模型:
客户端 Cookie → 服务端 Session优点:
- 安全
- 简单
缺点:
- 有状态
- 不适合分布式
5.2 JWT:无状态凭证
JWT 的本质:
将状态"自包含化"
它解决的问题是:
- 分布式场景下的认证状态传递
JWT 的设计哲学
- 不依赖服务端存储
- 信息自解释
- 可验证但不可篡改
优点:
- 天然适合微服务
- 可扩展
缺点:
- 难以撤销
- 长度较大
六、OAuth2:授权的标准化
OAuth2 并不是认证协议,而是:
授权协议
它解决的问题是:
第三方应用如何安全地访问用户资源
6.1 OAuth2 的核心抽象
四个角色:
- 资源所有者
- 客户端
- 授权服务器
- 资源服务器
本质:
将"用户授权"工程化
6.2 四种授权模式
| 模式 | 本质 |
|---|---|
| 授权码模式 | 最安全 |
| 隐式模式 | 纯前端场景 |
| 密码模式 | 高信任场景 |
| 客户端模式 | 无用户场景 |
6.3 OAuth2 的设计原则
- 最小权限
- 临时令牌
- 可撤销
- 明确边界
七、保密工程:安全的基础
认证与授权的底层,是密码学。
7.1 客户端加密的意义
客户端加密的本质不是传输安全,而是:
防止服务端被动暴露明文
7.2 密码存储的工程原则
- 永远不存明文
- 永远加盐
- 使用慢哈希
Bcrypt 的哲学
Bcrypt 的设计思想:
- 自带盐
- 自带成本因子
- 可随硬件升级
本质:
通过时间成本对抗算力进步
八、开放平台与边界信任
当系统从"内部系统"变为"开放平台",安全模型发生变化:
- 从默认信任
- 变为零信任
8.1 开放平台安全模型
核心要素:
- HTTPS
- 签名校验
- OAuth2
- API 网关
- 白名单 / 黑名单
本质:
构建受控的信任边界
九、服务间认证的本质
在微服务中,认证问题转化为:
服务与服务之间的信任问题
常见策略:
- mTLS
- API Key
- Token
- 证书
核心原则:
边界内信任,边界外验证
十、统一认知模型
最后,将所有内容抽象为一个统一框架:
安全体系├─ 认证│ ├─ 本地认证│ ├─ 联邦认证│ └─ SSO├─ 授权│ ├─ DAC│ ├─ RBAC│ ├─ ABAC│ └─ MAC├─ 凭证│ ├─ Session│ ├─ Token│ └─ JWT└─ 协议 ├─ OAuth2 └─ OIDC十一、设计哲学总结
认证与授权的根本原则:
- 最小权限原则
- 信任边界原则
- 零信任思想
- 纵深防御
- 可审计性
关联内容(自动生成)
- [/计算机网络/网络安全/安全性.html](/计算机网络/网络安全/安全性.html) 网关的安全防护能力与网络安全体系密切相关,包括认证、授权、安全策略执行、安全协议等方面的内容
- [/计算机网络/网络安全/安全架构.html](/计算机网络/网络安全/安全架构.html) 涉及网关在整体安全架构中的作用,包括边界安全、访问控制、安全策略执行等方面
- [/操作系统/安全.html](/操作系统/安全.html) 操作系统安全与网络安全在C.I.A安全基本原则、安全控制、安全评估方法等方面有共通之处,共同构建完整的安全防护体系
- [/计算机网络/网络安全/业务安全.html](/计算机网络/网络安全/业务安全.html) 业务安全的底层基于操作系统安全,操作系统的认证机制、保护域、访问控制等概念对业务安全身份体系建设有重要参考价值
- [/计算机网络/网络安全/Web安全.html](/计算机网络/网络安全/Web安全.html) Web安全与操作系统安全都涉及访问控制、权限管理、认证授权等概念,Web应用的安全最终需要操作系统的底层支持
- [/计算机网络/网络安全/网络安全技术.html](/计算机网络/网络安全/网络安全技术.html) 网络安全技术中的访问控制、权限管理与操作系统安全在安全模型、隔离技术等方面有共通之处,两者结合可构建端到端的安全防护体系
- [/计算机网络/网络安全/密码学/密码学.html](/计算机网络/网络安全/密码学/密码学.html) 密码学是认证与授权机制的基础,提供了身份认证、数据完整性保护、密钥管理等安全保障
- [/计算机网络/网络安全/渗透测试.html](/计算机网络/网络安全/渗透测试.html) 渗透测试中常关注认证与授权机制的弱点,涉及身份验证和权限管理的安全验证
- [/数据技术/合规与安全.html](/数据技术/合规与安全.html) 数据安全与操作系统安全在访问控制、权限管理、安全审计等方面有密切关联,操作系统安全是数据安全的基础保障
- [/计算机网络/网络安全/网络安全隔离技术.html](/计算机网络/网络安全/网络安全隔离技术.html) 网络隔离技术与操作系统安全在访问控制、权限管理、隔离等方面有共通之处,两者结合可构建端到端的安全防护体系