安全认证与访问控制

One Time Password一次性密码

平台认证

Basic Authentication 基本认证

是http协议内置的最简单的身份认证方式，常用与内网接口、测试环境、简单后台鉴权。

公网必须用HTTPS

客户端将用户名和密码拼接成字符串（admin:123456 base64编码: YWRtaW46MTIzNDU2）

放在请求头Authorization中，格式:Basic 编码后的字符串

如: Authorization: Basic YWRtaW46MTIzNDU2

服务端拿到后解码，校验用户名和密码是否正确

校验通过则正常相应，失败返回401 Unauthorized

服务器验证返回相应的资源和处理结果

Digest Auth 摘要认证

核心原理：Basic Auth的升级版，密码不直接Base64传输，而是通过哈希摘要校验。
特点：兼容HTTP基础协议、比Basic安全、无需额外Header。
适用场景：老旧系统、简单内网后台、替代不安全的Basic Auth。
安全评级：⭐⭐⭐

客户端如何使用 Digest Auth？

1.发送初步请求，获取 challenge 参数

importaxiosfrom'axios'// 初始请求资源URLconsturl='http://example.com/protected'// 第一次请求，预期会失败并获得 401 和 WWW-Authenticate 头axios.get(url).catch((error)=>{if(error.response&&error.response.status===401){constwwwAuthenticate=error.response.headers['www-authenticate']constauthDetails=parseWWWAuthenticate(wwwAuthenticate)performDigestAuth(authDetails,url)}})// 解析认证头信息的函数functionparseWWWAuthenticate(header){constparts=header.split(',')constdetails={}parts.forEach((part)=>{const[key,value]=part.split('=')details[key.trim()]=value.replace(/"/g,'')})returndetails}

2.使用认证参数和用户信息计算响应，发起认证请求

functionperformDigestAuth(authDetails,url){// 认证参数 authDetails 中包含realm, nonce等constusername='your_username'constpassword='your_password'constcnonce=generateCNonce()constnc='00000001'// Nonce count, 多次请求时递增constresponse=calculateDigestResponse(authDetails,username,password,cnonce,nc,)// 构造 Authorization 头constauthHeader=`Digest username="${username}", realm="${authDetails.realm}", nonce="${authDetails.nonce}", uri="${url}", response="${response}", opaque="${authDetails.opaque}", qop=${authDetails.qop}, nc=${nc}, cnonce="${cnonce}"`// 使用摘要认证信息再次发起请求axios.get(url,{headers:{Authorization:authHeader}}).then((response)=>{console.log('Authenticated Request Successful',response.data)}).catch((error)=>{console.log('Authenticated Request Failed',error)})}functiongenerateCNonce(){returnMath.random().toString(36).substring(7)}functioncalculateDigestResponse(authDetails,username,password,cnonce,nc){// 需要根据RFC 7616实现摘要计算// 示例仅为演示目的// 通常会涉及到MD5或其他散列函数生成responsereturn'Calculated response hash here'}

NTLM认证协议

一、核心定义

NTLM（NT LAN Manager） 是微软开发的质询-响应（Challenge-Response） 认证协议，是 Windows 传统默认认证，不传输明文密码，仅通过密码哈希完成验证，用于本地登录、工作组、域内降级认证、SMB共享、IIS网站等场景。

现状：Win2000后域环境默认Kerberos，NTLM仅作降级兜底（客户端/服务端不支持Kerberos、非域环境、跨网段） 。

二、核心原理

1. 客户端仅发送用户名明文，不发密码；

2. 服务端生成随机Challenge（16字节随机数） 下发；

3. 客户端用NTLM Hash加密Challenge生成Response回传；

4. 服务端（域环境则转发域控DC）比对Response，一致则认证通过 。

三、认证流程（极简3步握手）

1. 协商（Negotiate）：客户端发 NTLM_NEGOTIATE ，声明支持版本与能力；

2. 质询（Challenge）：服务端返回随机Challenge；

3. 响应（Authenticate）：客户端用NTLM Hash加密Challenge生成Response，服务端/DC验证通过即认证成功 。

域环境完整流程（客户端→服务端→DC）

1. 客户端发用户名给服务端；

2. 服务端生成Challenge并返回；

3. 客户端用NTLM Hash加密Challenge生成Response；

4. 服务端将「用户名+Challenge+Response」转发DC；

5. DC从SAM库取用户NTLM Hash，本地计算Response并比对；

6. DC返回结果，服务端通知客户端认证结果。

四、两个版本（安全差异极大）

1. NTLMv1（弱）

• 加密算法弱，易彩虹表、中继攻击；

• 哈希长度24字节，可快速爆破；

• 建议：生产环境禁用。

2. NTLMv2（强，推荐）

• 引入随机盐+时间戳，防重放；

• 哈希算法升级，抗破解；

• Windows默认推荐，组策略可强制启用v2。

五、核心特点

优点

• 兼容性极强，适配所有Windows版本；

• 无需第三方组件，配置简单；

• 非域/工作组环境唯一可用Windows认证；

• 不传输明文密码，基础安全性有保障。

缺点

• 单向认证：客户端无法验证服务端真伪，易钓鱼；

• 无票据机制，每次访问需重复认证，效率低；

• 存在哈希传递（PtH）、中继攻击高危漏洞；

• 无凭据委派，不支持跨域深度信任；

• 依赖NetBIOS，跨网段/防火墙体验差

Kerberos 网络身份验证协议

Token Authentication 令牌认证

方案1：JWT(无状态Token)

方案2: 随机Token+Redis（有状态）

小型项目、简单系统：用JWT

大型项目、需要注销、踢人：Redis+随机Token

用户提交账号密码，登录成功返回令牌（如：JWT）

前端把Token存在LocalStorage/SessionStorage/Cookie中

前端端每次请求请求头带上Token

放在请求头Authorization中，格式:Bearer token

如果令牌是有效的就认为客户已经登录过了

从令牌中提取客户的非敏感关键信息（如：用户编号）

根据用户信息查询用户所拥有的资源返回结果

OAuth Authentication 第三方授权登录

OAuth不是登录，是授权

微信登录、QQ登录、Github登录、Google登录

OAuth不传递账号密码，只传递授权凭证

OAuth里常见的三个令牌

code（授权码）：一次性，换token用

access_token：短期，用来访问用户资源

refresh_token: 长期，access_token过期后刷新用

用户点击微信登录

跳转到微信授权页

用户同意授权

微信返回授权码code给客户端

客户端拿着code去微信换取access_token拉取用户信息

登录成功，客户端自己生成JWT/Session给用户

API Key Authentication

Session-Cookie 会话认证

核心原理：服务端生成Session ID写入Cookie，客户端每次请求自动携带Cookie。
特点：传统Web最常用、简单、有状态、依赖Cookie。
适用场景：单体Web项目、管理后台、PC网站登录。
安全评级：⭐⭐⭐（配合HttpOnly、Secure后可到⭐⭐⭐⭐）

ip白名单/白名单认证

核心原理：服务端配置允许访问的IP列表，仅指定IP可调用接口。
特点：最简单、无侵入、防外部访问。
适用场景：内网接口、服务间调用、内部管理接口。
安全评级：⭐⭐（仅防外部，无法防内部泄露）

指纹/设备唯一标识认证

核心原理：客户端采集设备ID、指纹、系统信息生成唯一标识，服务端绑定校验。
特点：防多设备登录、防账号共享、防批量注册。
适用场景：APP登录、移动端接口、防刷接口。
安全评级：⭐⭐⭐

无密码认证(Magic Link / 免密登录)

核心原理：通过邮箱/短信发送一次性链接或验证码，点击即可登录，无需密码。
特点：用户体验好、无需记忆密码。
适用场景：个人网站、SaaS产品、移动端免密登录。
安全评级：⭐⭐⭐⭐

HMAC 签名认证（哈希消息认证码）

核心原理：客户端用「请求参数 + 时间戳 + 随机串 + 密钥」做哈希签名，服务端用相同规则校验签名。
特点：密钥不传输、防篡改、防重放、防参数伪造。
适用场景：对外公开API、高安全接口、支付回调、数据同步接口。
安全评级：⭐⭐⭐⭐⭐（比API Key安全很多）

mTls 双向证书认证

核心原理：客户端和服务端都持有SSL证书，双向校验身份，基于TLS层认证。
特点：底层加密、防中间人攻击、高安全、无Token泄露风险。
适用场景：微服务内部通信、金融、政务、物联网设备、内网核心服务。
安全评级：⭐⭐⭐⭐⭐（最高级别）

SSO(CAS/SAML) 单点登录

核心原理：基于标准协议的跨系统单点登录，一次认证多系统通行。
特点：企业级、标准化、跨域、跨系统。
适用场景：企业内部系统、高校平台、政府门户、多产品统一登录。
安全评级：⭐⭐⭐⭐

MFA 多因素认证

核心原理：组合两种以上认证方式（如密码+OTP+设备指纹）。
特点：叠加安全、防止单一方式泄露。
适用场景：后台管理、支付、敏感操作、企业账号。
安全评级：⭐⭐⭐⭐⭐

2FA双因素认证

一、核心定义

双因素认证（2FA） 是一种双重验证的安全机制。登录时，用户必须同时提供两种不同类型的身份凭证，才能完成认证。

核心逻辑：「你知道的」+「你拥有的」，即使密码泄露，黑客没有你的手机也无法登录。

二、认证三要素（2FA 从这里来）

安全认证的依据分为三类，2FA 就是任意两种的组合：

1. 知识因素（Something you know）：你知道的（密码、PIN码、密保问题）。

2. 持有因素（Something you have）：你拥有的（手机、硬件令牌、U盾、验证码器）。

3. 生物因素（Something you are）：你本身（指纹、人脸、虹膜）。

最常见组合：密码（知道） + 手机验证码（拥有）

三、常见 2FA 实现方式（按安全等级排序）

1. 短信验证码（SMS 2FA）

• 原理：输完密码，手机收 6 位数字短信。

• 优点：最简单、无需安装软件、普及率最高。

• 缺点：安全性最弱，易被SIM卡劫持（补卡攻击）、短信嗅探。

2. 软件令牌（TOTP，主流推荐）

• 工具：Google Authenticator、Microsoft Authenticator、阿里云/腾讯云令牌。

• 原理：基于时间同步，每30秒生成一个动态6位密码，断网也能用。

• 优点：安全性极高，不依赖运营商，无法被短信劫持。

• 缺点：手机丢了需要备份密钥。

3. 推送确认（Push 2FA）

• 原理：登录时手机APP弹窗「是否允许登录」，点确认即可。

• 优点：体验最好，不用输数字。

• 缺点：需要联网。

4. 硬件令牌（Hardware Key / U盾）

• 工具：YubiKey、银行U盾。

• 原理：物理插入设备，通过硬件加密芯片验证。

• 优点：绝对安全，无法远程劫持。

• 缺点：成本高、携带不便。

四、2FA 完整认证流程

1. 第一层（知识）：用户输入账号 + 密码（第一道门槛）。

2. 触发验证：密码正确后，系统不直接放行，要求二次验证。

3. 第二层（持有）：用户输入手机收到的动态验证码或APP动态码。

4. 认证通过：双重校验全部正确，才允许登录系统。

RBAC 基于角色的访问控制

RBAC = Role-Based Access Control（基于角色的访问控制）。

一、核心一句话

RBAC 不是认证协议，而是权限模型。
用户登录（Form/OAuth2/NTLM/Kerberos）只是认证；认证成功后，根据角色决定你能访问哪些接口/页面，这就是 RBAC 授权。

二、核心概念（四要素）

1. 用户 User：账号、人

2. 角色 Role：身份标签，如 admin 、 teacher 、 student 、 guest

3. 权限 Permission：具体操作，如 user:add 、 order:delete 、 system:config

4. 资源 Resource：接口、页面、按钮、菜单

关系：用户 → 角色 → 权限 → 资源

三、流程（最简版）

1. 用户登录认证（账号密码、2FA、Kerberos 都行）

2. 认证通过后，系统查出该用户的角色

3. 角色绑定了权限列表

4. 访问接口时，拦截器检查：当前角色是否拥有该接口权限

5. 有权放行，无权限拒绝（403）

一句话：
前面所有方式只负责“你是谁”，RBAC 负责“你能干嘛”。

四、RBAC 的四种经典模型

1. RBAC0（基础）：用户–角色–权限，最常用

2. RBAC1（分层角色）：角色可继承

3. RBAC2（约束）：互斥角色、会话限制

4. RBAC3（统一）：分层+约束，企业级最复杂

后端开发 99% 用 RBAC0 就够。

五、数据库表设计（通用）

1. user 用户表

2. role 角色表

3. user_role 用户角色关联表（多对多）

4. permission 权限表

5. role_permission 角色权限关联表（多对多）

六、代码层面（SpringBoot + Security 为例）

1. 登录成功返回用户角色： ROLE_ADMIN 、 ROLE_USER

2. 接口注解控制权限：

@PreAuthorize("hasRole('ADMIN')")@GetMapping("/admin")publicStringadmin(){return"管理员页面";}

3. 拦截器自动校验，无角色直接 403。

权限管理的两种类型

1. 菜单权限：控制用户能够访问的菜单项，通常以目录或菜单的形式展示。
2. 操作权限：控制用户能够执行的具体操作，通常以按钮或接口的形式实现。

菜单管理的实现逻辑

菜单管理的核心功能是展示系统中的菜单项与权限集合。在实际项目中，菜单管理通常通过以下步骤实现：

1. 查询权限集合：在用户登录时，系统会根据用户的角色查询其拥有的权限集合。
2. 生成菜单树：根据权限集合生成菜单树，展示用户能够访问的菜单项。
3. 展示菜单：将菜单树以树形结构展示在前端界面中。

后台管理系统权限设计

一句话模型：
给用户分配角色→ 角色绑定权限→ 权限控制能访问哪些菜单项，而这些菜单项通常组织成目录树