Django与Django REST Framework的认证/授权机制存在差异吗？
2026-8-4
Django 与 Django REST Framework (DRF) 认证/授权机制的差异
一、认证机制差异
Django 核心认证
- 主要适配传统Web浏览器场景，默认依赖session-cookie机制实现用户身份验证。
- 核心依赖
django.contrib.auth模块，默认使用ModelBackend等认证后端，处理用户登录、session创建与校验逻辑。 - 认证成功后，用户信息存储在
request.user中，但仅支持同步视图，认证逻辑相对固定，主要从表单提交或session中获取身份凭据。
DRF 认证
- 基于Django核心认证体系扩展，专门为API场景设计，支持多种无状态/有状态认证方式：Token认证、JWT认证、Session认证（需配置跨域适配前后端分离）、OAuth2等。
- 通过项目配置
REST_FRAMEWORK.DEFAULT_AUTHENTICATION_CLASSES全局指定认证类，也可在单个视图/视图集上单独配置，支持异步视图。 - 认证逻辑可插拔，会自动从请求头（如
Authorization: Token xxx）、请求参数等位置提取身份凭据，认证成功后同样将用户信息存入request.user，更贴合API的无状态交互需求。
二、授权机制差异
Django 核心授权
- 基于
django.contrib.auth的权限模型（Permission）与用户组（Group）实现，权限粒度主要为模型级或对象级。 - 通常通过
@permission_required装饰器在视图中校验权限，或在模板中用{% if perms.app.model %}判断权限，校验逻辑需开发者手动触发，未通过时一般跳转至登录页或返回403页面。
DRF 授权
- 兼容Django核心权限系统，同时扩展了一系列API友好的权限类：
IsAuthenticated、IsAdminUser、IsAuthenticatedOrReadOnly等，也支持自定义权限类。 - 通过
REST_FRAMEWORK.DEFAULT_PERMISSION_CLASSES全局配置，或视图类的permission_classes属性单独指定，会在视图处理请求自动校验权限，未通过时直接返回标准化的403 JSON响应，适配API的交互逻辑。 - 支持更灵活的对象级权限校验，可通过重写自定义权限类的
has_object_permission方法，实现针对单个资源实例的权限控制。
补充说明
DRF的认证/授权并非完全独立于Django核心体系，而是在其基础上做了API场景的适配与扩展：比如DRF仍使用Django的用户模型（或自定义用户模型），权限数据也存储在Django的权限表中，只是在逻辑层面更贴合API的无状态、标准化响应需求。
内容的提问来源于stack exchange，提问作者Temka
相关产品推荐
相关产品推荐
