认证与授权（Authentication & Authorization）的原理与实现

1. 概念与区别

• 认证（Authentication）：验证用户身份，解决“你是谁”的问题。例如，用户输入用户名和密码登录系统。
• 授权（Authorization）：验证用户是否有权限执行操作，解决“你能做什么”的问题。例如，管理员可删除文章，普通用户只能浏览。
• 关系：认证是授权的前提，系统需先确认用户身份，再根据其角色或权限控制访问。

2. 认证的常见方式与原理

（1）会话- Cookie 认证

• 流程：
  1. 用户提交凭证（如密码），服务端验证通过后创建会话（Session），存储用户ID等数据。
  2. 服务端返回 Cookie（包含 Session ID）给浏览器，浏览器后续请求自动携带该 Cookie。
  3. 服务端通过 Session ID 查找会话数据，验证用户身份。
• 安全性：Session ID 需随机生成且设置过期时间，避免被窃取后伪造身份。

（2）Token 认证（如 JWT）

• 流程：
  1. 用户登录后，服务端生成 Token（包含用户信息、签名、过期时间），返回给客户端。
  2. 客户端后续请求在 Header（如 Authorization: Bearer <token>）中携带 Token。
  3. 服务端验证 Token 签名与有效期，无需存储会话状态。
• 优势：无状态，适合分布式系统；但 Token 一旦签发，在过期前无法强制失效。

3. 授权的核心模型

（1）基于角色的访问控制（RBAC）

• 原理：
  • 定义角色（如管理员、编辑、游客），为角色分配权限（如“删除文章”“修改设置”）。
  • 用户通过关联角色间接获得权限。
• 示例：

  -- 数据库表结构  
  Users: id, name, role_id  
  Roles: id, name  
  Permissions: id, action  -- 如 "article:delete"  
  Role_Permissions: role_id, permission_id  
  

• 检查逻辑：查询用户所属角色是否具有某项操作的权限。

（2）基于属性的访问控制（ABAC）

• 原理：根据动态属性（用户部门、资源类型、时间等）定义策略。
• 示例：

  策略：允许“部门A的员工”在“工作时间”访问“部门A的文档”。  
  

• 优势：更灵活，但策略管理复杂。

4. 实现案例：RBAC 中间件设计

以 Web 框架的中间件为例，检查用户权限：

def permission_required(permission):  
    def decorator(view_func):  
        @wraps(view_func)  
        def wrapped_view(request, *args, **kwargs):  
            # 1. 从请求中获取用户（通过认证中间件已附加）  
            user = request.user  
            # 2. 检查用户是否拥有权限  
            if not user.has_permission(permission):  
                return HttpResponse("Forbidden", status=403)  
            return view_func(request, *args, **kwargs)  
        return wrapped_view  
    return decorator  

# 使用示例  
@permission_required("article:delete")  
def delete_article(request):  
    # 删除文章逻辑  
    pass  

5. 安全注意事项

• 认证安全：
  • 密码需加盐哈希存储（如 bcrypt）。
  • 使用 HTTPS 防止凭证泄露。
  • 设置登录尝试次数限制，防暴力破解。
• 授权安全：
  • 默认拒绝所有请求，仅显式允许必要权限。
  • 服务端必须校验权限，客户端校验仅用于体验优化。

6. 扩展：OAuth 2.0 与 OpenID Connect

• OAuth 2.0：授权第三方应用访问用户资源（如用微信登录第三方网站），不涉及身份认证。
• OpenID Connect：在 OAuth 2.0 基础上添加身份认证层，提供用户信息接口。

通过以上步骤，系统可安全地管理用户身份与权限，适应不同规模的业务场景。