每个开发者都应该知道的7个认证概念

视频来源：7 Authentication Concepts Every Developer Should Know
作者：Hayk Simonyan（YouTube技术博主，10.2万订阅者，聚焦后端、安全开发领域）
发布时间：2026年2月18日｜ 播放数据：发布1个月内播放量达226,796次
本篇文章为视频内容的深度总结与技术拓展，旨在帮助开发者系统掌握身份认证的核心知识。

核心内容概述

本文从基础概念区分到底层技术逻辑，再到企业级协议落地，层层拆解开发者必备的7个身份认证核心概念。内容覆盖从入门级的HTTP基础认证，到现代开发主流的Token认证、MFA多因素认证，再到企业级的SSO单点登录、服务间认证协议，形成了完整的认证知识体系，厘清认证领域易混淆的关键知识点（如认证与授权、OAuth2.0与OIDC的区别）。

一、认证（Authentication）与授权（Authorization）

这是认证领域最基础且易被混淆的概念，二者为访问控制体系的前后置核心环节，逻辑上不可逆，功能上完全独立，是开发者构建安全系统的首要认知基础。

1.1 核心定义

维度	认证（Authentication）	授权（Authorization）
核心问题	你是谁？	你能做什么？
核心目标	验证身份真实性	分配资源访问权限
时序	先执行，权限验证的前提	后执行，依赖认证结果
实现方式	凭据验证（密码、Token等）	权限策略（角色、属性、动态规则）
典型技术	OAuth2、JWT、Session	RBAC、ABAC、PBAC
典型实现	账号密码验证、JWT令牌校验、指纹识别、证书验证	RBAC（基于角色的权限控制）、ABAC（基于属性的权限控制）、资源访问策略配置

1.2 核心关联

无认证则无授权，认证是授权的基础；授权是认证的延伸，仅对已验证身份的主体生效。

flowchart LR
    A[用户请求访问资源] --> B{认证通过?}
    B -->|否| C[拒绝访问]
    B -->|是| D{授权通过?}
    D -->|否| E[权限不足]
    D -->|是| F[允许访问]
    
    style A fill:#e1f5fe
    style C fill:#ffebee
    style E fill:#fff3e0
    style F fill:#e8f5e9

关键要点：

认证：验证身份真实性，回答”你是谁”的问题，是所有权限分配的前置必要条件
授权：分配权限范围，回答”你能做什么”的问题，是认证后的资源管控环节

二、认证因子（Authentication Factors）

认证因子是所有认证方式的底层设计依据，是验证用户身份的核心维度，分为三类核心因子，可单独使用（单因素认证）或组合使用（多因素认证，MFA），组合使用也是提升认证安全性的核心手段。

2.1 因子分类概览

mindmap
  root((认证因子))
    知识因子
      密码
      PIN码
      密保问题
    持有因子
      手机短信验证码
      OTP令牌
      U盾
      数字证书
    固有因子
      指纹
      面部识别
      声纹
      虹膜扫描
    辅助因子
      IP地址
      设备指纹
      行为特征

2.2 三类核心认证因子详解

因子类型	核心定义	典型示例	安全等级	适用场景	衍生技术
知识因子（Something you know）	仅用户自身知晓的秘密信息	静态密码、PIN码、密保问题、支付密码	低	普通网站登录、小型系统内部访问	动态密码生成、密码复杂度校验、密码哈希存储（bcrypt/Argon2）
持有因子（Something you have）	用户实际持有且可验证的实体/电子设备	手机（短信/推送验证码）、U盾、OTP令牌、数字证书、FIDO硬件密钥	中-高	金融APP登录、企业系统访问、API调用认证	TOTP/HOTP一次性口令、证书链验证、硬件密钥加密签名
固有因子（Something you are）	用户独有的生物特征（生理/行为）	指纹、面部识别、虹膜扫描、声纹、行为轨迹（如鼠标操作）	高	手机解锁、金融支付、高安全等级系统登录	活体检测（眨眼/摇头）、生物特征特征值脱敏存储、多生物特征融合验证

2.3 辅助认证因子

用于补充验证，提升认证的精准度和风控能力，不单独作为认证依据，仅与核心因子配合使用：

辅助因子类型	具体内容
网络因子	IP地址、网段、运营商
设备因子	设备指纹、机型、系统版本、唯一设备标识
行为因子	登录时间、常用登录地点、操作习惯

2.4 技术延伸：生物特征认证核心参数

不同生物特征的**误识率（FAR）和拒真率（FRR）**决定其安全等级和应用成本：

生物特征	误识率（FAR）	拒真率（FRR）	应用成本	适用场景
指纹识别	0.001%	1%	低	普通场景
人脸识别	0.01%	2%	中	普通场景
虹膜识别	0.0001%	0.5%	高	金融、军工等高安全场景

三、基础认证（Basic Authentication）

HTTP协议内置的最简认证方式，属于单因素认证（知识因子），实现逻辑简单但安全性极低。

3.1 核心实现逻辑

客户端将账号:密码拼接为字符串，通过Base64编码生成认证字符串
客户端在HTTP请求头中添加Authorization: Basic <Base64编码字符串>，传递给服务端
服务端对编码字符串进行Base64解码，获取账号密码并验证
验证通过则返回资源，失败则返回401 Unauthorized响应

1
2
3

GET /api/resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

其中 dXNlcm5hbWU6cGFzc3dvcmQ= 是 username:password 的 Base64 编码。

3.2 核心缺陷

缺陷类型	详细说明
Base64是编码而非加密	解码过程可逆，若未加密传输，账号密码可被直接破解
无会话管理	每次请求均需传递凭据，重复传输增加泄露风险
无防爆破机制	协议本身未提供登录失败次数限制、超时等风控能力
无令牌过期机制	一旦凭据泄露，攻击者可永久使用

3.3 使用要求与适用场景

要求/场景	说明
强制要求	必须配合HTTPS使用，通过加密传输降低泄露风险
适用场景	仅适用于内部测试、低安全需求的小型自用系统
严禁	生产环境单独使用

3.4 代码示例

// 前端发送基础认证请求
fetch('https://api.example.com/resource', {
  headers: {
    'Authorization': 'Basic ' + btoa('username:password')
  }
});

// ⚠️ 生产环境不推荐使用

四、令牌认证（Token Authentication）

现代开发的主流认证方案，替代传统的Cookie+Session模式，核心是通过加密令牌标识用户身份，支持无状态会话设计，适配跨域、多端（PC/移动端/小程序）、微服务架构。

4.1 令牌核心分类

根据令牌是否携带用户信息，分为两类，核心差异在于是否需要服务端存储和是否支持无状态认证。

flowchart TB
    subgraph Opaque["不透明令牌 (Opaque Token)"]
        O1["随机字符串<br/>如: UUID"]
        O2["服务端需查表验证"]
        O3["可随时撤销"]
    end
    
    subgraph JWT["JWT (JSON Web Token)"]
        J1["Header.Payload.Signature"]
        J2["服务端无状态验证"]
        J3["难以即时撤销"]
    end
    
    O1 --> O2 --> O3
    J1 --> J2 --> J3
    
    style Opaque fill:#fff3e0
    style JWT fill:#e8f5e9

4.1.1 不透明令牌（Opaque Token）

特性	说明
本质	随机生成的字符串（如UUID、雪花算法ID），令牌本身不携带任何用户信息
验证逻辑	服务端需通过查表/调用验证接口（如Redis、数据库），根据令牌查询对应的用户身份和权限信息
优点	令牌无信息泄露风险，可随时通过服务端删除令牌实现即时撤销，安全性高
缺点	服务端需存储令牌信息，存在性能开销，不支持纯无状态认证
适用场景	对令牌撤销有实时要求的场景，如企业后台、金融系统

4.1.2 JSON Web Token（JWT）

目前最主流的令牌格式，属于自包含令牌，自带用户核心信息，支持无状态认证，其标准由IETF制定（RFC 7519）。

官方标准文档：RFC 7519 - JSON Web Token (JWT)

核心结构：由Header.Payload.Signature三部分组成，各部分通过Base64编码后用.拼接：

1	`xxxxx.yyyyy.zzzzz`

部分	内容示例	说明
Header	`{"alg": "HS256", "typ": "JWT"}`	声明令牌的加密算法（如HS256、RS256）和令牌类型
Payload	`{"sub": "user123", "exp": 1234567890}`	存储用户核心信息，支持自定义字段，不可存储敏感信息（因Base64编码可逆）
Signature	签名值	服务端用密钥对Header和Payload的编码结果进行签名，防止令牌被篡改

flowchart LR
    subgraph JWT["JWT Token"]
        H[Header<br/>Base64] --> P[Payload<br/>Base64]
        P --> S[Signature<br/>HMACSHA256]
    end
    
    style H fill:#bbdefb
    style P fill:#c8e6c9
    style S fill:#ffccbc

JWT特性	说明
验证逻辑	服务端无需查表，仅通过密钥验证签名的有效性，并检查令牌的过期时间（exp字段），实现纯无状态认证
优点	服务端无需存储令牌，支持无限水平扩展，跨域/多端适配友好，请求效率高
缺点	Payload非加密存储，存在信息泄露风险；令牌一旦签发无法即时撤销（除非引入黑名单机制）
优化方案	设置短有效期（几分钟~1小时），配合刷新令牌使用；采用非对称加密（RS256）提升签名安全性；不存储敏感信息

4.2 令牌分层设计：Access Token & Refresh Token

为解决JWT撤销难、过期管理复杂的问题，采用令牌分层设计，将令牌分为访问令牌和刷新令牌，各司其职，平衡安全性和便捷性。

sequenceDiagram
    participant C as 客户端
    participant A as 认证服务器
    participant R as 资源服务器
    
    C->>A: 1. 登录请求
    A-->>C: 2. 返回 Access Token + Refresh Token
    
    C->>R: 3. 携带 Access Token 访问资源
    R-->>C: 4. 返回资源
    
    Note over C,R: Access Token 过期后...
    
    C->>A: 5. 使用 Refresh Token 刷新
    A-->>C: 6. 返回新的 Access Token

Access Token（访问令牌）

特性	说明
定位	短期有效令牌，有效期通常为5分钟~1小时
功能	直接用于访问系统API接口，作为身份凭证
设计原则	有效期越短越好，即使泄露，影响范围和时间也有限

Refresh Token（刷新令牌）

特性	说明
定位	长期有效令牌，有效期通常为1天~30天
功能	仅用于换取新的访问令牌，不参与任何接口访问
设计原则	严格保护，存储在服务端受保护存储（如Redis），支持即时撤销；客户端需加密存储（如移动端的Keychain、后端的服务器内存）

令牌管理原则：

Access Token：短有效期，用于API访问
Refresh Token：长有效期，仅用于刷新令牌，需严格保护

五、多因素认证（Multi-Factor Authentication，MFA）

组合两种及以上核心认证因子的认证方式，是提升系统安全性的核心手段。MFA通过增加”第二道/第三道验证防线”，即使单一因子（如密码）泄露，攻击者因缺少其他因子也无法完成认证，大幅降低身份盗用风险。

5.1 核心设计原则

必须组合不同类型的核心认证因子（如知识因子+持有因子、知识因子+固有因子），不可组合同类型因子
兼顾安全性和便捷性，避免因验证步骤过于繁琐导致用户体验下降
高安全场景优先选择无网络依赖的验证方式（如TOTP、硬件密钥），降低中间人攻击风险

5.2 主流实现方式对比

实现方式	组合因子	实现逻辑	安全等级	适用场景	官方/技术参考
短信/邮件OTP	知识因子+持有因子	服务器向用户手机/邮箱发送一次性验证码，用户输入验证	★★☆☆☆	普通APP登录、账号找回	短信网关接口、邮件SMTP协议
TOTP/HOTP	知识因子+持有因子	服务器与用户设备共享密钥，基于时间（TOTP）/事件（HOTP）生成6位动态验证码，30秒内有效	★★★★☆	企业系统、云服务、GitHub登录	Google Authenticator、Microsoft Authenticator
推送确认认证	知识因子+持有因子	用户登录时，服务器向绑定设备推送确认消息，用户点击”确认”完成验证	★★★★☆	金融APP、社交平台	各厂商推送服务（如FCM、APNs）
生物特征+密码	知识因子+固有因子	密码验证后，叠加指纹/面部识别等生物特征验证	★★★★★	手机支付、金融APP、高安全等级系统	各平台生物识别SDK
FIDO2/WebAuthn硬件密钥	持有因子+固有因子（可选）	硬件密钥存储公钥/私钥对，登录时通过USB/NFC感应，设备生成加密签名完成认证，无需输入密码	★★★★★	企业SSO、金融核心系统、军工/政府系统	FIDO2/WebAuthn 官方标准

5.3 技术延伸：OTP一次性口令分类

OTP是MFA中最常用的持有因子验证方式，分为TOTP（基于时间）和HOTP（基于事件）：

类型	同步机制	特点	代表产品
TOTP（基于时间的一次性密码）	与NTP服务器时间同步，每30秒生成一次新验证码，时钟偏差超过30秒则失效	时钟依赖	Google Authenticator
HOTP（基于事件的一次性密码）	基于计数器同步，每验证一次计数器加1，计数器不同步则失效	计数器依赖	RSA SecurID

六、会话管理（Session Management）

认证通过后维持用户身份的核心机制，直接影响系统的安全性、扩展性和多端适配性。分为两种主流的会话管理方案：传统有状态会话（Cookie+Session）和现代无状态会话（基于Token）。

6.1 方案对比

flowchart TB
    subgraph Session["有状态 Session"]
        S1[用户登录] --> S2[服务端生成session_id]
        S2 --> S3[存储到Redis/DB]
        S3 --> S4[Set-Cookie返回]
    end
    
    subgraph Token["无状态 Token"]
        T1[用户登录] --> T2[服务端签发JWT]
        T2 --> T3[客户端存储Token]
        T3 --> T4[请求携带Token]
    end
    
    style Session fill:#e1f5fe
    style Token fill:#e8f5e9

核心实现流程

用户认证通过后，服务端生成唯一的session_id，并将用户身份/权限信息存储在服务端（内存、Redis、数据库）
服务端通过HTTP响应头Set-Cookie，将session_id发送至客户端浏览器
客户端浏览器自动将session_id存储在Cookie中，后续每次请求均自动携带Cookie，传递给服务端
服务端通过session_id查表，获取用户身份信息，完成身份验证

核心安全配置（必须配置）

属性	作用	安全价值
`HttpOnly`	禁止JavaScript读取Cookie	防止XSS攻击窃取Cookie
`Secure`	仅HTTPS传输	防止中间人攻击
`SameSite`	限制跨域传递（Strict/Lax/None）	减少CSRF攻击风险
`Max-Age/Expires`	设置过期时间	避免永久有效
`Domain/Path`	限制生效域名和路径	缩小作用范围

优缺点

维度	说明
优点	实现简单、技术成熟，服务端可随时删除session_id实现强制登出/踢人，令牌撤销实时性高
缺点	服务端需存储会话状态，水平扩展难度大（需共享会话存储）；Cookie存在跨域限制，多端适配性差；存在XSS/CSRF攻击风险（需额外配置防护）

6.3 现代无状态会话：基于Token

核心实现流程

用户认证通过后，服务端签发Token（JWT/不透明令牌），返回给客户端
客户端将Token存储在LocalStorage/SessionStorage/移动端Keychain中，后续每次请求手动携带Token（如请求头Authorization: Bearer <Token>）
服务端验证Token的有效性（签名、过期时间），无需查表，直接完成身份验证

优缺点

维度	说明
优点	服务端无需存储会话状态，支持无限水平扩展；无Cookie跨域限制，多端/跨域适配友好；避免XSS/CSRF攻击风险
缺点	令牌管理逻辑复杂，需处理过期、刷新、撤销问题；JWT无法即时撤销（需引入黑名单机制）；客户端存储Token存在泄露风险（需加密存储）

6.4 方案选择指南

场景	推荐方案	原因
传统Web应用	Cookie+Session	成熟稳定，易于实现注销
SPA/移动端	JWT	跨域友好，无状态扩展
微服务架构	JWT + 网关验证	服务间无需共享会话存储
高安全系统	Session + 双因素	可即时撤销，审计完整

七、企业级认证协议与框架

针对第三方授权、单点登录（SSO）、服务间认证等复杂开发场景的标准化解决方案，是企业级开发中开发者必须掌握的核心知识。

7.1 协议对比总览

协议	核心定位	典型场景	数据格式
OAuth 2.0	授权框架	第三方授权登录	JSON
OIDC	认证协议	企业SSO	JSON
SAML 2.0	认证协议	传统企业SSO	XML
mTLS	服务间认证	微服务/零信任	证书

7.2 OAuth 2.0

全球主流的授权框架，非认证协议，核心解决**”第三方应用在用户授权下，访问用户在资源服务器上的资源，且无需获取用户账号密码”**的问题。

官方标准文档：The OAuth 2.0 Protocol (IETF)

OAuth 2.0特性	说明
核心定位	授权框架，仅负责权限分配，不负责身份认证
核心角色	资源所有者（用户）、客户端（第三方应用）、授权服务器、资源服务器
典型场景	“用微信登录小红书”、”用Google登录GitHub”、”用支付宝登录饿了么”

核心授权模式

授权模式	安全等级	适用场景
授权码模式（Authorization Code）	最高	服务端应用（如网站、后端服务）
简化模式（Implicit）	中	纯前端应用（如SPA单页应用）
密码模式（Password）	低	信任的内部应用（如企业内部系统）
客户端凭证模式（Client Credentials）	中	服务间认证（如微服务间调用、API接口调用）

OAuth 2.0 授权流程

sequenceDiagram
    participant U as 用户
    participant C as 客户端
    participant AS as 授权服务器
    participant RS as 资源服务器
    
    U->>C: 1. 访问第三方应用
    C->>U: 2. 重定向到授权服务器
    U->>AS: 3. 用户登录并授权
    AS-->>C: 4. 返回授权码
    C->>AS: 5. 用授权码换取Token
    AS-->>C: 6. 返回Access Token
    C->>RS: 7. 携带Token访问资源
    RS-->>C: 8. 返回资源

重要提示：OAuth 2.0 是授权框架而非认证协议，仅负责授权，不直接验证用户身份。

7.3 OpenID Connect（OIDC）

基于OAuth2.0扩展的认证协议，弥补了OAuth2.0无身份认证能力的缺陷。

OIDC特性	说明
核心定位	认证协议，基于OAuth2.0构建，兼具身份认证和授权能力
核心扩展	在OAuth2.0的基础上，增加了ID Token（JWT格式），用于传递用户身份信息
典型场景	企业统一身份平台，员工通过一个账号登录企业内部所有系统
优点	基于OAuth2.0，兼容性强，实现简单，支持跨域/多端

OIDC vs OAuth 2.0

flowchart LR
    subgraph OAuth["OAuth 2.0"]
        OA[授权]
    end
    
    subgraph OIDC["OpenID Connect"]
        O1[授权]
        O2[认证<br/>+ID Token]
        O3[用户信息]
    end
    
    OAuth --> OIDC
    
    style OAuth fill:#fff3e0
    style OIDC fill:#e8f5e9

7.4 SAML 2.0

基于XML的企业级认证协议，是传统企业SSO的标准解决方案。

官方标准文档：SAML 2.0 Technical Overview (OASIS)

SAML 2.0特性	说明
核心定位	认证协议，基于XML实现身份信息的跨域传递
核心逻辑	通过SAML断言（Assertion）传递用户身份信息
典型场景	大型传统企业、政府机构的多系统统一登录（如银行、电信、政府内部系统）
优点	兼容性强，适用于传统企业架构，支持复杂的权限策略
缺点	基于XML，解析复杂，传输体积大，适配移动端/轻量应用难度高

7.5 mTLS（双向TLS）

服务对服务的高安全认证协议，是TLS单向认证的扩展，核心实现客户端与服务器的双向身份验证。

官方标准文档：Mutual TLS Profile for OAuth 2.0 (IETF)

mTLS特性	说明
核心定位	服务间认证协议，基于X.509证书实现双向认证，是零信任架构的核心技术之一
典型场景	微服务之间的内部调用、金融级API接口、零信任架构、政府/军工的高安全服务通信

与单向TLS的区别

类型	验证方式	适用场景
单向TLS	仅客户端验证服务器的证书	普通网站/APP（如HTTPS）
双向TLS（mTLS）	客户端验证服务器证书 + 服务器验证客户端证书	微服务间调用、金融级API

实现逻辑

服务端和客户端均需拥有X.509数字证书（由CA机构签发）
建立连接时，服务器向客户端发送自身证书，客户端验证通过后，向服务器发送自身证书
服务器验证客户端证书的有效性，验证通过则建立加密连接，失败则拒绝连接

7.6 补充协议：Kerberos & X.509

协议	说明
Kerberos	基于对称加密的集中式认证协议，适用于企业内部局域网的认证，核心解决”密钥分发”问题
X.509	基于PKI（公钥基础设施）的数字证书标准，是mTLS、SSL/TLS、数字签名的底层基础

八、认证开发最佳实践

8.1 安全准则清单

mindmap
  root((认证安全))
    密码安全
      使用bcrypt/scrypt/Argon2
      随机salt
      可选pepper
    防护措施
      限制登录失败次数
      指数退避机制
      CAPTCHA验证
      IP/设备指纹检测
    传输安全
      强制HTTPS
      敏感数据加密传输
    权限管理
      最小权限原则
      定期权限审计
    令牌管理
      合理过期时间
      Refresh Token加密存储
      黑名单撤销机制

8.2 详细实践指南

实践领域	核心准则
密码存储	绝不存储明文密码，使用专用哈希算法（bcrypt、scrypt、Argon2推荐），为每个用户生成随机salt，可选添加pepper（服务器端密钥）
防爆破与风控	限制登录失败次数（如5次后锁定账号）、设置指数退避机制（如失败后等待1s/2s/4s），配合CAPTCHA/滑块验证，结合IP/设备指纹检测可疑登录行为
加密传输	所有认证相关数据（密码、令牌、验证码、证书）必须通过HTTPS传输，防止明文泄露
最小权限原则	授权时仅为用户分配完成业务所需的最小权限，避免过度授权导致的风险，定期清理无用权限
定期审计	记录所有认证/授权操作日志（如登录时间、IP、设备、操作行为），定期检查权限分配和日志，及时发现异常访问与权限滥用
令牌管理	JWT设置合理的短有效期，Refresh Token单独加密存储并支持即时撤销，建立令牌黑名单机制（如Redis）处理紧急撤销需求
证书管理	使用mTLS时，定期更新X.509证书，及时撤销过期/泄露的证书，采用证书链验证提升安全性
用户体验平衡	在提升安全性的同时，兼顾用户体验，避免验证步骤过于繁琐（如高安全场景用硬件密钥，普通场景用TOTP/推送确认）

8.3 代码实践示例

密码哈希（推荐）

const bcrypt = require('bcrypt');

// 密码加密
const hashedPassword = await bcrypt.hash(password, 10);

// 密码验证
const isValid = await bcrypt.compare(inputPassword, hashedPassword);

JWT 签发与验证

const jwt = require('jsonwebtoken');

// 签发令牌
const accessToken = jwt.sign(
  { userId: '123', role: 'user' },
  process.env.JWT_SECRET,
  { expiresIn: '15m' }
);

// 验证令牌
try {
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  console.log(decoded.userId);
} catch (err) {
  // Token无效或过期
}

安全的Cookie配置

// Express.js 示例
res.cookie('sessionId', sessionToken, {
  httpOnly: true,      // 防XSS
  secure: true,        // 仅HTTPS
  sameSite: 'strict',  // 防CSRF
  maxAge: 3600000      // 1小时过期
});

九、认证方式全景对比

为方便开发者快速选型，以下对所有核心认证方式进行全面对比：

认证方式	核心类型	安全等级	实现难度	状态特性	跨域支持	多端适配	典型适用场景	核心优点	核心缺点
基础认证	单因素（知识因子）	★☆☆☆☆	★☆☆☆☆	无状态	支持	一般	内部测试、低安全小型系统	实现极简单	安全性极低，Base64编码可逆
Cookie+Session	单因素/多因素	★★★☆☆	★★☆☆☆	有状态	不支持	差	传统单体应用	实现简单，可即时撤销	扩展性差，存在XSS/CSRF风险
不透明令牌	单因素/多因素	★★★★☆	★★★☆☆	半无状态	支持	好	企业后台、金融系统	可即时撤销，安全性高	服务端需存储令牌
JWT令牌	单因素/多因素	★★★☆☆	★★★☆☆	无状态	支持	好	微服务、跨域应用	无状态，扩展性强	无法即时撤销，Payload存在泄露风险
短信/邮件OTP	双因素	★★☆☆☆	★★☆☆☆	无状态	支持	好	普通APP登录	实现简单，用户体验好	安全性低，易遭SIM卡劫持
TOTP/HOTP	双因素	★★★★☆	★★★☆☆	无状态	支持	好	企业系统、云服务	安全性高，无网络依赖	需用户安装专用APP
FIDO2/WebAuthn	双因素	★★★★★	★★★★☆	无状态	支持	好	企业SSO、金融核心系统	安全性极高，防密码泄露	需用户购买硬件密钥
OAuth 2.0	第三方授权框架	★★★★☆	★★★★☆	无状态	支持	好	第三方登录	无需获取用户密码，兼容性强	仅为授权框架，无认证能力
OIDC	认证协议	★★★★☆	★★★★☆	无状态	支持	好	企业SSO	兼具认证和授权	依赖OAuth2.0
SAML 2.0	认证协议	★★★★☆	★★★★★	无状态	支持	差	传统企业SSO	兼容性强，支持复杂权限策略	基于XML，解析复杂
mTLS	服务间认证	★★★★★	★★★★★	无状态	支持	好	微服务间调用、金融API	双向认证，安全性极高	证书管理复杂

总结

本文从基础概念 → 核心因子 → 具体实现 → 协议框架 → 最佳实践，系统梳理了身份认证的7个核心知识点：

认证与授权：厘清核心区别与时序关系，认证是授权的前置条件
认证因子：理解三类核心因子（知识、持有、固有）及其组合应用
基础认证：掌握HTTP Basic Auth的实现与局限，仅适用于测试环境
令牌认证：深入JWT结构与Token刷新机制，理解无状态认证的优势与挑战
多因素认证：平衡安全性与用户体验，TOTP和硬件密钥是推荐方案
会话管理：有状态与无状态方案的选择，根据架构特点灵活选型
协议框架：OAuth2.0、OIDC、SAML、mTLS等企业级方案的定位与适用场景

掌握这些概念，将帮助你在实际开发中构建更安全、更可靠的身份认证系统。

技术总结 > 安全开发

#认证 #安全 #后端开发 #OAuth #JWT

每个开发者都应该知道的7个认证概念

https://zhenyu-cpu.github.io/2026/03/24/2026-03-24-每个开发者都应该知道的7个认证概念/

作者

zhenyu

发布于

2026年3月24日

许可协议

Hello World 上一篇

每个开发者都应该知道的7个认证概念

核心内容概述

一、认证（Authentication）与授权（Authorization）

1.1 核心定义

1.2 核心关联

二、认证因子（Authentication Factors）

2.1 因子分类概览

2.2 三类核心认证因子详解

2.3 辅助认证因子

2.4 技术延伸：生物特征认证核心参数

三、基础认证（Basic Authentication）

3.1 核心实现逻辑

3.2 核心缺陷

3.3 使用要求与适用场景

3.4 代码示例

四、令牌认证（Token Authentication）

4.1 令牌核心分类

4.1.1 不透明令牌（Opaque Token）

4.1.2 JSON Web Token（JWT）

4.2 令牌分层设计：Access Token & Refresh Token

Access Token（访问令牌）

Refresh Token（刷新令牌）

五、多因素认证（Multi-Factor Authentication，MFA）

5.1 核心设计原则

5.2 主流实现方式对比

5.3 技术延伸：OTP一次性口令分类

六、会话管理（Session Management）

6.1 方案对比

6.2 传统有状态会话：Cookie+Session

核心实现流程

核心安全配置（必须配置）

优缺点

6.3 现代无状态会话：基于Token

核心实现流程

优缺点

6.4 方案选择指南

七、企业级认证协议与框架

7.1 协议对比总览

7.2 OAuth 2.0

核心授权模式

OAuth 2.0 授权流程

7.3 OpenID Connect（OIDC）

OIDC vs OAuth 2.0

7.4 SAML 2.0

7.5 mTLS（双向TLS）

与单向TLS的区别

实现逻辑

7.6 补充协议：Kerberos & X.509

八、认证开发最佳实践

8.1 安全准则清单

8.2 详细实践指南

8.3 代码实践示例

密码哈希（推荐）

JWT 签发与验证

安全的Cookie配置

九、认证方式全景对比

总结