Introduction to Django's Auth System

Django comes with a built-in security guard that already knows how to check IDs, remember visitors, and lock doors, so you don't have to build one yourself.

In this page:

What django.contrib.auth Provides
request.user in Every View
The MIDDLEWARE Setting

What django.contrib.auth Provides

Django's auth app provides a User model, login/logout views, password hashing, permissions, and groups out of the box. It is listed in INSTALLED_APPS in every new project.

Note: You rarely need to write authentication logic yourself — Django already solved it.

Example: What django.contrib.auth Provides

These are the default apps Django adds to every new project; 'django.contrib.auth' is what powers users, permissions and login.

markup

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

{# Django-only code -- models.py/views.py/urls.py/settings.py snippets, or template markup using Django template tags/variables -- can't run standalone via Judge0 or the browser preview, since it needs a real Django project. Only this course's pure-Python examples (example_lang == 'python', no Django imports) are actually runnable, so those still get the button below. #}

request.user in Every View

AuthenticationMiddleware attaches a user object to every incoming request. If nobody is logged in, request.user is an AnonymousUser instead of None.

Warning: Removing AuthenticationMiddleware from MIDDLEWARE breaks request.user everywhere.

Example: request.user in Every View

is_authenticated is False for AnonymousUser and True for a real logged-in User, so this check never crashes.

markup

from django.http import HttpResponse

def whoami(request):
    if request.user.is_authenticated:
        return HttpResponse(f'Hello, {request.user.username}')
    return HttpResponse('Hello, anonymous visitor')

The MIDDLEWARE Setting

SessionMiddleware and AuthenticationMiddleware must both be present, in that order, for logins to work: sessions store the login, and auth middleware reads the session.

Note: Order matters — AuthenticationMiddleware depends on SessionMiddleware running first.

Example: The MIDDLEWARE Setting

SessionMiddleware must come before AuthenticationMiddleware because auth reads the logged-in user id out of the session.

markup

MIDDLEWARE = [
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
]

Common Mistakes

Assuming django.contrib.auth needs to be installed separately — it ships with every new Django project by default.
Writing custom login/password-checking code instead of using the battle-tested auth system already provided.
Forgetting that AuthenticationMiddleware must stay in MIDDLEWARE for request.user to be available in views.

Chapter Summary

django.contrib.auth is Django's built-in app for users, passwords, sessions, and permissions.
It is enabled by default via INSTALLED_APPS and AuthenticationMiddleware in settings.py.
Every request gets a request.user object — either a real logged-in User or an AnonymousUser.
The system handles password hashing, login sessions, and permission checks so you don't build them from scratch.

🔒

Chapter Quiz — Complete all 12 topics to unlock

0/12 topics done

Complete these topics first:

← Previous Lesson Pagination in Django Next Lesson → The User Model Overview

Introduction to Django's Auth System

What django.contrib.auth Provides

request.user in Every View

The MIDDLEWARE Setting

Chapter Quiz — Complete all 12 topics to unlock

Login to run this code