# 认证管你是谁，鉴权管你能干啥，别再混着用了

- 发布日期: 2024-01-23 · 分类: Technology

做安全方向这些年，我被问得最多的一个问题就是："认证和鉴权到底有什么区别？"很多刚入行的同学会把这两个词混着用，简历上写"负责用户认证与鉴权模块"，面试官一追问就卡壳。今天我把这两个概念掰开了讲，顺便聊聊工程里怎么落地。

## 先说认证：你到底是谁

认证（Authentication）解决的就是一个事儿——证明你确实是你说的那个人。线下你刷脸进小区、按指纹开手机，都是认证。到了数字世界，凭证的形态更多样，但本质没变：系统得拿到某种证据，确认对面坐着的不是冒充者。

我日常接触到的认证手段，大致分三档：

- 密码：最老、最基础，也是被爆破最多的。
- 二因素认证：密码之外再叠一道，比如短信验证码、TOTP 令牌。我实测下来，光加一个短信 OTP 就能挡住绝大多数自动化撞库，但防不住 SIM 卡被物理劫持的情况。
- 数字证书：基于非对称密钥对做加密校验，银行 U 盾、企业内网登录常见。

身份确认完了，接下来就是鉴权（Authorization）——回答"你能做什么"。我一般这么跟新人解释：认证是保安查你工牌，鉴权是门禁系统决定你能刷开哪几扇门的磁吸锁。迈过门槛是一回事，进哪间房是另一回事。

实现层面，我见过的项目里用得最多的几套机制：

- 访问控制列表（ACLs）：逐条写死"用户 A 能读资源 X，不能写资源 Y"。小系统够用，规模一大就维护噩梦。
- 基于角色的访问控制（RBAC）：先定义角色（管理员、编辑、只读），再把用户挂到角色上，权限跟着角色走。我做过的项目里 RBAC 是绝对主力，权限变更不用动用户表。
- 策略引擎：一组声明式规则，界定"什么条件下允许执行什么操作"。AWS IAM Policy 就是典型，JSON 里写 Allow/Deny，灵活但写复杂了容易出漏洞。

我踩过一次坑。早期有个内部工具，登录走 OAuth 没问题，但后端接口没做鉴权，任何登录用户都能调管理员接口改配置。等于家里装了防盗门，进去之后保险柜、书房、车库全敞着。反过来我也见过只做了权限表、没做身份校验的接口，谁都能拿个伪造的 token 进来，满屋子小锁，但到底谁拿着钥匙，日志里查不到。

所以我的判断很明确：认证和鉴权是两道独立的防线，一道都不能省。

## 工程里怎么选协议

落到代码层面，我手边常翻的协议就四个：

- **OIDC（OpenID Connect）**：在 OAuth 2.0 之上加了一层身份能力。客户端先验证用户身份，再拿到基础个人信息（姓名、邮箱这些）。我最常用它做 SSO，前后端分离架构下体验最顺。
- **OAuth 2.0**：严格说是个授权框架，让第三方应用在不索要用户密码的前提下，访问用户在另一服务上的资源。它聚焦"授权"本身，不直接做身份验证，但实际项目里经常被拿来当授权流程的骨架。
- **SAML 2.0（安全断言标记语言）**：一套 XML 标准，用于身份提供者（IdP）和服务提供者（SP）之间交换验证与授权断言。企业环境里的 SSO 很多还是靠它，用户一次登录就能访问十几个内部系统。
- **CAS（Central Authentication Service）**：面向 Web 应用的单点登录协议，多应用切换只需登录一次。高校场景用得最多，校园网内外应用的登录都能被它串起来。

## 最后说两句

攻击手段这两年确实越来越花，钓鱼、凭据填充、供应链投毒，防不胜防。但回到基本盘，用户侧把多重认证打开，企业侧把权限策略写周全，能挡掉绝大多数低级攻击。每次点"登录"那一下，背后连着的是一整条身份链路。把认证和鉴权这两件事做扎实，比堆花哨的安全设备管用得多。