How does Django's authentication system work?
Understand how Django authentication works: authenticate(), login(), backends, session middleware, password hashing, permissions and how to guard views.
Expected Interview Answer
Django's authentication system verifies who a user is (authentication) and what they can do (authorization) using the User model, configurable authentication backends, and session-based login state managed through middleware.
When a user submits credentials, authenticate() runs each backend in AUTHENTICATION_BACKENDS until one returns a User; login() then stores that user's id in the session. On every subsequent request, AuthenticationMiddleware reads the session and attaches request.user (a real User or AnonymousUser). Passwords are never stored in plain text — they are hashed with a configurable hasher like PBKDF2. Authorization is layered on top through permissions, groups, and the is_authenticated / is_staff / is_superuser flags, enforced by decorators like @login_required or permission mixins.
- Secure password hashing out of the box (PBKDF2 by default)
- Pluggable backends for LDAP, tokens, or social login
- Session-based login state with middleware handling request.user
- Built-in permissions and groups for authorization
- Ready-made decorators and mixins to guard views
AI Mentor Explanation
Authentication is the gate steward checking a player's registration card before letting them onto the field — that is authenticate(). Once verified, the player gets a wristband (the session) so they need not re-prove identity at every boundary. Permissions are like being cleared to bat, bowl, or captain: verified entry and specific role privileges are separate checks.
Step-by-Step Explanation
Step 1
Submit credentials
A login view collects username and password and calls authenticate(request, username=..., password=...).
Step 2
Run backends
authenticate() tries each backend in AUTHENTICATION_BACKENDS; the first to return a User wins.
Step 3
Start the session
login(request, user) stores the user's id in the session, so the browser gets a session cookie.
Step 4
Attach request.user
On later requests, AuthenticationMiddleware reads the session and sets request.user to the User or AnonymousUser.
Step 5
Authorize actions
Views enforce access with @login_required, permission checks, groups, and is_staff/is_superuser flags.
What Interviewer Expects
- Separates authentication from authorization
- Knows authenticate() + login() + AuthenticationMiddleware flow
- Mentions password hashing (PBKDF2) not plain text
- Understands AUTHENTICATION_BACKENDS pluggability
- Knows permissions, groups, and @login_required
Common Mistakes
- Confusing authentication with authorization
- Thinking passwords are stored in plain text
- Forgetting that login() is needed after authenticate()
- Assuming request.user is set without AuthenticationMiddleware
Best Answer (HR Friendly)
“Django checks a user's password against a securely hashed record, and if it matches it remembers them using a session cookie so they stay logged in. On top of that, it tracks permissions and groups to control what each user is allowed to do.”
Code Example
from django.contrib.auth import authenticate, login
from django.contrib.auth.decorators import login_required
from django.shortcuts import render, redirect
def login_view(request):
if request.method == 'POST':
user = authenticate(
request,
username=request.POST['username'],
password=request.POST['password'],
)
if user is not None:
login(request, user) # stores user id in the session
return redirect('dashboard')
return render(request, 'login.html')
@login_required
def dashboard(request):
return render(request, 'dashboard.html', {'user': request.user})Follow-up Questions
- How does Django hash and verify passwords?
- What is the difference between authenticate() and login()?
- How do you write a custom authentication backend?
- How do permissions and groups work in Django?
- How would you implement a custom User model?
MCQ Practice
1. Which function stores the logged-in user's id in the session?
login() persists the authenticated user's id in the session; authenticate() only verifies credentials.
2. What sets request.user on each request?
AuthenticationMiddleware reads the session and attaches a User or AnonymousUser to request.user.
3. By default, how are Django passwords stored?
Django hashes passwords with PBKDF2 (and salt) by default; hashers are configurable and never reversible.
Flash Cards
authenticate() vs login()? — authenticate() verifies credentials and returns a User; login() stores that user in the session.
What attaches request.user? — AuthenticationMiddleware, by reading the session on each request.
How are passwords stored? — Hashed (PBKDF2 by default) with a salt — never in plain text.
Authentication vs authorization? — Authentication proves identity; authorization decides what that identity may do via permissions/groups.