Какими способами реализуется аутентификация в Django
Что проверяют
Понимаете ли вы, как устроена встроенная аутентификация Django и где начинаются DRF и сторонние пакеты. Следом спрашивают, как хранятся пароли и как сделать вход по email вместо имени пользователя.
Как отвечать
Начните с django.contrib.auth:
- сессии: способ по умолчанию.
authenticate()проверяет учётные данные через бэкенды,login()пишет пользователя в сессию, браузер получает кукуsessionid, аAuthenticationMiddlewareкладёт пользователя вrequest.user. Сессии по умолчанию лежат в базе. Вьюхи закрывают@login_requiredиLoginRequiredMixin, с Django 5.1 естьLoginRequiredMiddleware; - бэкенды: список
AUTHENTICATION_BACKENDS, по умолчаниюModelBackend. Свой бэкенд с методамиauthenticateиget_userдаёт вход по email или телефону,django-auth-ldapподключает LDAP,RemoteUserBackendдоверяет заголовку от прокси с SSO; - пароли: хранятся хэшем, по умолчанию PBKDF2, Argon2 включают через
argon2-cffiиPASSWORD_HASHERS, требования задаютAUTH_PASSWORD_VALIDATORS; - своя модель пользователя:
AUTH_USER_MODELна базеAbstractUser.
Для API в Django REST Framework:
SessionAuthentication: свой фронтенд на том же домене, с проверкой CSRF;TokenAuthentication: один бессрочный токен на пользователя, в базе он лежит открытым текстом, годится для простых интеграций;- JWT: через
djangorestframework-simplejwt, короткий access и refresh с ротацией и чёрным списком.
Вход через внешних провайдеров по OAuth 2.0 и OpenID Connect дают django-allauth и social-auth-app-django, второй фактор django-otp или модуль MFA в allauth.
Где спотыкаются
Меняют модель пользователя на живом проекте. Миграции и внешние ключи на auth.User делают это болезненной операцией, поэтому свою модель заводят сразу, даже пустую.
Выбирают JWT по умолчанию и кладут его в localStorage. Для своего фронтенда сессия с HttpOnly-кукой проще и безопаснее, а JWT без чёрного списка до истечения не отозвать.
Путают authenticate() и login(): первая только проверяет и возвращает пользователя или None, сессию создаёт вторая.