FastAPI如何对接现有Django认证体系复用用户登录会话

你调研的两个方案里，OAuth2改造完全没必要，会额外增加大量改造成本，还可能影响现有线上登录逻辑，不符合你不改动Django侧的要求；直接读数据库会话的方向是对的，但不需要自己手动实现会话解析逻辑，直接复用Django自带的能力即可，是当前场景下成本最低、兼容性最好、维护成本最小的方案。

• 配置FastAPI侧加载Django运行环境
  因为两个服务部署在同服务器、共享同一个数据库，只需要在FastAPI启动时加载Django的配置文件，即可直接复用Django的ORM、会话、用户模型等全部能力，不需要额外做数据库同步：

  import os
  import sys
  import django
  from django.conf import settings
  
  # 替换为你的Django项目根目录绝对路径，解决模块导入找不到的问题
  sys.path.append("/path/to/your/django/project/root")
  # 替换为你的Django项目实际的settings模块路径
  os.environ.setdefault("DJANGO_SETTINGS_MODULE", "your_project.settings")
  django.setup()
  

• 编写FastAPI依赖项实现登录态校验
  直接调用Django自带的SessionStore完成会话解析、有效性校验，不需要手动查django_session表、自己实现解码和签名校验逻辑：

  from fastapi import Depends, Request, HTTPException, status
  from django.contrib.sessions.backends.db import SessionStore
  from django.contrib.auth import get_user_model
  
  User = get_user_model()
  
  def get_login_user(request: Request):
      # 从Cookie中读取Django默认种下的会话ID，如果你自定义了SESSION_COOKIE_NAME就替换为对应值
      session_key = request.cookies.get(settings.SESSION_COOKIE_NAME)
      if not session_key:
          raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="未登录")
      
      # 复用Django原生会话校验逻辑，自动处理过期判断、签名校验、数据解码
      session = SessionStore(session_key=session_key)
      user_id = session.get("_auth_user_id")
      if not user_id:
          raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="无效登录态")
      
      try:
          user = User.objects.get(id=user_id, is_active=True)
      except User.DoesNotExist:
          raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail="用户不存在")
      
      return user
  

• 接口层直接注入依赖即可获取当前登录用户
  所有需要登录才能访问的FastAPI接口，加上依赖注入即可自动完成身份校验，和Django自带的login_required装饰器效果完全一致：

  from fastapi import FastAPI, Depends
  
  app = FastAPI()
  
  @app.get("/api/table/update")
  def get_updated_table_data(login_user: User = Depends(get_login_user)):
      # 这里可以直接用login_user做权限判断、查询关联数据
      return {"code": 0, "msg": "success", "data": []}
  

• 你的场景是在Django模板中发起异步请求，属于同域调用，浏览器会自动携带Django种下的sessionidCookie，不需要前端做额外的Token传递、跨域配置，请求逻辑和普通Django视图完全一致。
• 如果你的Django开启了SESSION_COOKIE_SECURE、SESSION_COOKIE_HTTPONLY等安全配置，FastAPI侧不需要做任何调整，Cookie会被浏览器正常携带。
• 不要自己手动解析django_session表的session_data字段：Django的SessionStore已经封装了签名校验、数据解码、过期判断的全部逻辑，自己手动实现很容易漏校验导致安全漏洞，也会在后续Django升级会话逻辑时出现兼容问题。
• 如果需要开启CSRF校验，直接复用Django的CSRF校验逻辑即可，模板中渲染的{% csrf_token %}可以直接被FastAPI侧校验通过，不需要额外生成新的Token。

• 零侵入：完全不需要修改Django侧任何现有代码，原有登录、登出、权限逻辑不受任何影响，用户只需要在Django侧登录一次，即可正常访问两端的所有需要鉴权的资源。
• 逻辑一致：所有会话校验规则和Django原生逻辑完全对齐，不会出现两边登录状态不同步、权限判断标准不统一的问题。
• 维护成本极低：后续Django版本升级、用户模型调整、会话配置修改，FastAPI侧不需要做额外适配，只要能正常加载Django配置即可自动对齐逻辑。
• 性能开销极小：会话查询是直接读同实例的数据库，和Django本身处理请求时的会话查询逻辑完全一致，没有额外的网络调用开销。

内容的提问来源于stack exchange，提问作者GRA