接口权限验证有哪些方式
接口权限验证是保障 API 安全的核心机制，常见的方式有以下几类，适用于不同场景和安全需求：
1. 基于令牌（token）的验证
（1）JWT（JSON Web Token）
原理：
服务器验证用户身份后，生成包含用户信息（如角色、权限）的加密令牌（Header.Payload.Signature），返回给客户端。客户端后续请求时在 Header 中携带令牌，服务器解密并验证签名有效性。
流程：
用户登录 → 服务器生成 JWT → 客户端存储（localStorage/cookie）
客户端请求接口 → Header 携带 Authorization: Bearer
服务器验证 token 有效性 → 解析权限信息 → 允许 / 拒绝访问
特点：
无状态（服务器不存储 token），适合分布式系统；token 可包含权限信息，减少数据库查询；过期时间可控。
（2）OAuth 2.0 + Token
原理：
第三方授权协议，允许用户通过第三方平台（如微信、GitHub）授权访问资源，核心是通过授权服务器生成访问令牌（Access Token）。
场景：
开放平台（如微信支付 API、GitHub API），允许第三方应用有限度访问用户资源。
流程：
授权码模式（最常用）→ 用户授权 → 第三方应用获取授权码 → 换取 Access Token → 用 Token 调用接口。
2. 基于 Session 的验证
原理：
用户登录后，服务器创建 Session（存储用户信息和权限），生成 Session ID 返回给客户端（通常存在 Cookie 中）。客户端后续请求携带 Session ID，服务器通过 ID 查找 Session 验证权限。
特点：
服务器需存储 Session（内存 / Redis），有状态；依赖 Cookie，可能受 CSRF 攻击（需配合 CSRF Token 防护）；适合单体应用。
3. 基于 API 密钥（API Key）的验证
原理：
服务端为客户端分配唯一 API Key（如字符串密钥），客户端请求时在 Header / 参数中携带，服务器验证 Key 的有效性和关联权限。
场景：
内部服务间调用、第三方合作接口（如天气 API、支付接口）。
示例：Header: X-API-Key: abc123456
特点：
简单易实现，但 Key 明文传输风险高，需配合 HTTPS；适合服务级别的验证，而非用户级。
4. 基于 HMAC 签名的验证
原理：
客户端按规则（如时间戳 + 请求参数 + 密钥）生成哈希签名（如 SHA256），与请求一起发送。服务器用相同规则重新计算签名，对比一致性验证身份和数据完整性。
特点：
密钥不直接传输，防篡改；通常结合时间戳防止重放攻击（如签名有效期 5 分钟）；适合高安全性接口（如金融、支付）。
5. 基于角色的访问控制（RBAC）
原理：
不直接验证用户，而是验证用户所属的角色和角色对应的权限（如管理员、普通用户）。权限与角色绑定，角色与用户绑定。
流程：
预定义角色（如 admin、user）和权限（如 read:data、write:data）
用户登录后，服务器获取其角色 → 检查角色是否拥有接口所需权限
特点：
灵活易扩展，适合多用户、多权限场景（如后台管理系统）；常与 Token/Session 结合使用。
6. 基于 IP 的访问控制
原理：
服务器配置允许访问的 IP 白名单，仅白名单内的 IP 地址可调用接口。
场景：
内部服务间固定 IP 通信（如数据库接口、内部统计 API），不暴露给公网。
特点：
简单直接，但 IP 可伪造（需结合其他验证）；适合限制来源的封闭场景。
7. 组合验证方式
实际开发中常结合多种方式提升安全性，例如：
- JWT + RBAC：Token 携带用户角色，服务器验证 Token 后检查角色权限。
- API Key + HMAC：服务间通信时，用 API Key 标识身份，HMAC 确保请求未被篡改。
- Session + CSRF Token：基于 Session 验证时，添加 CSRF Token 防止跨站请求伪造。