🔐 Django Authentication System

Authentication vs. Authorization

These two words are easy to blur, but the distinction runs through everything in this lesson:

• Authentication proves identity — "you are who you claim to be." Logging in with a password is authentication.
• Authorization checks permission — "you're allowed to do this." Deciding whether you can delete an article is authorization.

💡 The office-building analogy: Authentication is showing your badge at the front desk to get inside. Authorization is whether that badge opens the server-room door. You can be authenticated (inside the building) yet not authorized (locked out of a room).

The User Model

The default User model stores a username, hashed password, email, names, the is_active/is_staff/is_superuser flags, and join/login timestamps.

Creating users the safe way

from django.contrib.auth import get_user_model, authenticate

User = get_user_model()

# ALWAYS use create_user — it hashes the password. Never User.objects.create().
user = User.objects.create_user(
    username="ada",
    email="ada@example.com",
    password="a-strong-passphrase",
)

# Verifying credentials returns the user or None
who = authenticate(username="ada", password="a-strong-passphrase")
if who is not None:
    ...  # credentials good

Define a custom user model on day one

Django strongly recommends a custom user model for every new project — even one that starts identical to the default. Swapping it later, once tables and foreign keys exist, is painful.

💡 Buy the roomier suit: A custom user model is like buying a suit with a little extra room. You may not need the space today, but altering it later is far cheaper than replacing the whole thing after your database is full of related rows.

# accounts/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models


class User(AbstractUser):
    bio = models.TextField(blank=True)
    birth_date = models.DateField(null=True, blank=True)

# settings.py — set this BEFORE the first migration
AUTH_USER_MODEL = "accounts.User"

Logging in with email instead of username

To drop usernames entirely, subclass AbstractUser, remove username, make email the identifier, and supply a manager:

# accounts/models.py
from django.contrib.auth.models import AbstractUser, BaseUserManager
from django.db import models


class UserManager(BaseUserManager):
    def create_user(self, email, password=None, **extra):
        if not email:
            raise ValueError("Users must have an email address.")
        user = self.model(email=self.normalize_email(email), **extra)
        user.set_password(password)     # hashes it
        user.save(using=self._db)
        return user

    def create_superuser(self, email, password=None, **extra):
        extra.setdefault("is_staff", True)
        extra.setdefault("is_superuser", True)
        return self.create_user(email, password, **extra)


class User(AbstractUser):
    username = None
    email = models.EmailField("email address", unique=True)

    USERNAME_FIELD = "email"
    REQUIRED_FIELDS = []                 # email & password are prompted automatically

    objects = UserManager()

Login, Logout & Registration

Django ships class-based views for login, logout, and the whole password-reset flow. You supply templates; Django supplies the logic.

Built-in auth views

# accounts/urls.py
from django.contrib.auth import views as auth_views
from django.urls import path

urlpatterns = [
    path("login/",  auth_views.LoginView.as_view(template_name="accounts/login.html"), name="login"),
    path("logout/", auth_views.LogoutView.as_view(), name="logout"),

    # Forgot-password flow (needs email configured)
    path("password-reset/", auth_views.PasswordResetView.as_view(), name="password_reset"),
    path("password-reset/done/", auth_views.PasswordResetDoneView.as_view(), name="password_reset_done"),
    path("reset/<uidb64>/<token>/", auth_views.PasswordResetConfirmView.as_view(), name="password_reset_confirm"),
    path("reset/done/", auth_views.PasswordResetCompleteView.as_view(), name="password_reset_complete"),
]

Registration

Django has no built-in signup view, but UserCreationForm does the heavy lifting — including running the password validators:

# accounts/forms.py
from django import forms
from django.contrib.auth.forms import UserCreationForm
from django.contrib.auth import get_user_model

User = get_user_model()


class RegisterForm(UserCreationForm):
    email = forms.EmailField(required=True)

    class Meta:
        model = User
        fields = ["username", "email", "password1", "password2"]


# accounts/views.py
from django.contrib.auth import login
from django.shortcuts import render, redirect
from .forms import RegisterForm


def register(request):
    form = RegisterForm(request.POST or None)
    if request.method == "POST" and form.is_valid():
        user = form.save()
        login(request, user)             # log them in right away
        return redirect("home")
    return render(request, "accounts/register.html", {"form": form})

Sessions

HTTP is stateless — each request arrives with no memory of the last. Sessions bridge that gap: on login, Django stores session data server-side and hands the browser a signed cookie holding only the session key. Every later request presents that cookie, and Django re-loads who's logged in.

Reading and writing session data

# A guest shopping cart, kept in the session
def add_to_cart(request, product_id):
    cart = request.session.setdefault("cart", {})
    cart[str(product_id)] = cart.get(str(product_id), 0) + 1
    request.session.modified = True      # required when mutating nested data
    return redirect("cart")

Permissions & Protecting Views

For every model, Django auto-creates four permissions: add_, change_, delete_, and view_. You can add your own in the model's Meta:

class Article(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)

    class Meta:
        permissions = [
            ("publish_article", "Can publish articles"),
        ]

Protecting function-based views

from django.contrib.auth.decorators import login_required, permission_required


@login_required
def profile(request):
    return render(request, "accounts/profile.html")


@permission_required("blog.publish_article", raise_exception=True)
def publish(request, pk):
    article = get_object_or_404(Article, pk=pk)
    article.status = "published"
    article.save()
    return redirect("article_detail", pk=pk)

Protecting class-based views

from django.contrib.auth.mixins import LoginRequiredMixin, PermissionRequiredMixin
from django.views.generic import UpdateView


class ArticleUpdateView(LoginRequiredMixin, PermissionRequiredMixin, UpdateView):
    model = Article
    fields = ["title", "content"]
    permission_required = "blog.change_article"
    raise_exception = True

Checking permissions in templates

{% if perms.blog.publish_article %}
    <a href="{% url 'publish' article.pk %}">Publish</a>
{% endif %}

{% if user.is_authenticated %}
    <span>Hi, {{ user.get_username }}</span>
{% else %}
    <a href="{% url 'login' %}">Log in</a>
{% endif %}

Groups & Roles

Assigning permissions to individual users doesn't scale. Instead, bundle permissions into groups and put users in groups — this is role-based access control (RBAC).

from django.contrib.auth.models import Group, Permission

editors, _ = Group.objects.get_or_create(name="Editors")
publish = Permission.objects.get(codename="publish_article")
editors.permissions.add(publish)

user.groups.add(editors)                 # user now inherits "publish_article"

if user.groups.filter(name="Editors").exists():
    ...  # user is an editor

Real example: a news site with Writers (edit their own drafts), Editors (edit and publish anything), and Admins (manage users). Groups and their permissions are also fully manageable through the Django admin.

Object-Level Access

Model permissions are all-or-nothing: "can change any article." Often you want "can change my own article." That's object-level access, and the simplest approach is an explicit ownership check.

from django.core.exceptions import PermissionDenied


@login_required
def edit_article(request, pk):
    article = get_object_or_404(Article, pk=pk)
    if article.author != request.user:
        raise PermissionDenied           # → 403
    # ... proceed with the edit

In class-based views, filter the queryset so users simply can't reach rows they don't own (a missing row yields a clean 404):

class ArticleUpdateView(LoginRequiredMixin, UpdateView):
    model = Article
    fields = ["title", "content"]

    def get_queryset(self):
        return Article.objects.filter(author=self.request.user)

Security Best Practices

Enforce strong passwords

# settings.py
AUTH_PASSWORD_VALIDATORS = [
    {"NAME": "django.contrib.auth.password_validation.UserAttributeSimilarityValidator"},
    {"NAME": "django.contrib.auth.password_validation.MinimumLengthValidator",
     "OPTIONS": {"min_length": 10}},
    {"NAME": "django.contrib.auth.password_validation.CommonPasswordValidator"},
    {"NAME": "django.contrib.auth.password_validation.NumericPasswordValidator"},
]

Secure cookies and HTTPS (production)

# settings.py — production
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True             # cookies only over HTTPS
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True           # JS can't read the session cookie
SECURE_HSTS_SECONDS = 31_536_000         # 1 year
SECURE_HSTS_INCLUDE_SUBDOMAINS = True

Hands-on Exercise

# accounts/views.py
from django.contrib.auth import login
from django.contrib.auth.decorators import login_required
from django.contrib.auth.forms import UserCreationForm
from django.shortcuts import render, redirect


def register(request):
    form = UserCreationForm(request.POST or None)
    if request.method == "POST" and form.is_valid():
        user = form.save()
        login(request, user)
        return redirect("profile")
    return render(request, "accounts/register.html", {"form": form})


@login_required
def profile(request):
    return render(request, "accounts/profile.html")

# accounts/urls.py
from django.contrib.auth import views as auth_views
from django.urls import path
from . import views

urlpatterns = [
    path("register/", views.register, name="register"),
    path("profile/",  views.profile,  name="profile"),
    path("login/",    auth_views.LoginView.as_view(
        template_name="accounts/login.html"), name="login"),
    path("logout/",   auth_views.LogoutView.as_view(), name="logout"),
]

# settings.py
LOGIN_URL = "login"
LOGIN_REDIRECT_URL = "profile"
LOGOUT_REDIRECT_URL = "login"

Summary & Quiz

📚 Further Reading

• Django docs — Using the authentication system
• Django docs — Customizing authentication (custom user model)
• Django docs — Password management
• OWASP Top 10 — common security risks

🚀 What's Next?

You've covered Django's server-rendered core. Next we shift toward APIs: building RESTful services with Flask-RESTful, where authentication and validation reappear in a lighter, API-first framework.