Free through lesson 3

Intro to Authentication & Membership Features

From storing passwords, sessions and cookies, and CSRF, through email verification, social login (OAuth 2.0), plans and roles, rate limiting and two-factor authentication, all the way to audit logs and account deletion. Across 30 lessons you'll get to the point where you can build a membership site's login from end to end yourself. All code and test results were actually run against Django 6.1.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are split into 6 chapters. We recommend working through them in order starting from Chapter 1, but feel free to skim just the parts you're curious about. * Django can't run in the browser, so try it in a virtual environment with Django, pytest-django, and pyotp installed. Examples that only need the standard library, like OAuth's state or rate limiting, can run right there in the browser. This course assumes you've taken the Django course.

Chapter 1 — Fundamentals of Authentication (lessons 1–5)

Store passwords as hashes, keep login state with sessions and cookies, and reject spoofed POSTs with a CSRF token — confirm the foundations of authentication using Django's built-in features. We finish by seeing that login and logout really just mean recording and clearing a user ID in the session.

1

Storing Passwords with a Salted Hash

Why you never store a password in plaintext and instead keep a salted, one-way hash. How make_password and check_password give the same password a different hash every time.

Free
2

Keeping a Login Alive with Sessions and Cookies

HTTP forgets everything between requests. How the actual data lives in a server-side session while the browser only gets a sessionid cookie, and what HttpOnly, Secure, and SameSite mean.

Free
3

Blocking Spoofed POSTs with a CSRF Token

CSRF tricks a logged-in user's browser into sending a spoofed POST from another site. Confirm a tokenless POST gets rejected with 403, and the form's csrf_token and X-CSRFToken header roles.

Free
4

Why You Don't Build Authentication Yourself

Leave hashing, sessions, CSRF, and strength checks to the built-in features. Confirm validate_password rejects short and common passwords, and draw the line at building only your own business logic.

🔒 Basic
5

What Login and Logout Really Are

Verify with authenticate, record into the session with login, and clear it with logout. Confirm "logged in" just means the session holds a user ID, and authentication vs. authorization.

🔒 Basic

Chapter 2 — Email Verification and Login (lessons 6–11)

Send a confirmation email at signup, verify the address with a token link, and build password-free login codes and resets. We finish by rejecting weak passwords before signup and covering SMTP along with SPF, DKIM, and DMARC so your emails don't land in spam.

6

Create a User at Signup

Create a user with create_user, whose password is automatically hashed for you. Combine a member's Profile and a confirmation email into a single view, and confirm the whole path from signup to login.

🔒 Basic
7

Verify an Address with a Confirmation Email Token

Build a time-limited token unique to that user with default_token_generator, and put it in the confirmation email's link. Confirm that clicking the link flips email_verified from False to True.

🔒 Basic
8

Time-Limited Login Codes (Magic Links)

Log in with a time-limited link sent by email instead of a password. Build a token with an expiry and tamper detection using django.core.signing, and confirm the valid, expired, and tampered cases.

🔒 Basic
9

Password Reset and Time-Limited Tokens

A reset's core is a time-limited token only the right person can use. Change the password with set_password, and confirm the old link stops working. Uses production's built-in PasswordResetView.

🔒 Basic
10

Validate Password Strength Before Registration

Run validate_password before create_user so a user with a weak password never gets created. The four built-in validators, and the idea that length matters more than complexity rules.

🔒 Basic
11

Sending Email and SMTP Configuration

The basics of send_mail, and switching backends between in-memory (locmem) for development and SMTP for production. SPF, DKIM, and DMARC so your auth emails don't land in spam.

🔒 Basic

Chapter 3 — Social Login (lessons 12–18)

Break down the OAuth 2.0 authorization code flow behind "Sign in with Google" into the authorization URL, state, callback, and token exchange, and confirm each step. Cover key handling and account linking for each provider, then finish with why you should hand this off to django-allauth in production.

12

The OAuth 2.0 Authorization Code Flow

The OAuth 2.0 behind "Sign in with Google." How the flow connects authorization URL → consent → code → token exchange without ever handing your password to the app, and its URL parameters.

🔒 Basic
13

Prevent Login Hijacking with state

state is OAuth's easiest parameter to forget and its most dangerous one to skip. Generate an unguessable random value, save it to the session, and compare it in constant time at the callback.

🔒 Basic
14

Receive code and state at the Callback

The provider redirects back to your registered redirect_uri with code and state attached. Why you check state before using code, and the exact-match rule behind the common redirect_uri mismatch error.

🔒 Basic
15

Exchange the Authorization Code for a Token

Exchange the authorization code from the callback for an access token and id_token, server to server. Writing a test that injects the HTTP call, and why client_secret must never reach the browser.

🔒 Basic
16

Keys and Settings for Google, GitHub, LINE, and X

Collect each provider's authorization endpoint and scope into one table, and build all four authorization URLs with one function. Key points for each developer console, and never hardcoding keys.

🔒 Basic
17

Link a Social Account to a User

Social login only ever gives you the provider's uid. Make (provider, uid) unique and link it to your user to prevent duplicates. The callback's three branches, and why you don't auto-link by email.

🔒 Basic
18

Hand Social Login Off to django-allauth

django-allauth fully handles state verification, callback, token exchange, and account linking. How hard this is to build gap-free yourself, and which settings stay your job even after adopting it.

🔒 Basic

Chapter 4 — Storing Member State (lessons 19–23)

Attach a one-to-one Profile to User to hold plan and role, and separate out who's allowed to do what. Build the logic that shows full content only to paying members and controls the free preview, and finish by making sure no login-required page slips through unprotected.

19

Extend the User Model with Profile

Hold plan, role, and email verification — none of which built-in User has — in a one-to-one Profile. Checking default values, and the criteria for choosing between a Profile and a custom User model.

🔒 Basic
20

Separate What's Allowed with Permissions and Roles

Authorization (what's allowed) differs from authentication (who you are). Gate admin features via Profile's role and is_staff, when to move to Groups/Permissions, and why checks stay server-side.

🔒 Basic
21

Gate Content by Plan

Check Profile's plan and return 401 for logged-out users, 402 for free, and 200 for paid. Updating the plan is billing's job — this course only builds the container that gates content by plan.

🔒 Basic
22

Cut Off the Free Preview on the Server

visible_content returns the first 100 characters for free and the full text for paid. Never send the paid portion at all rather than blur it with CSS, and make the cutoff feel natural.

🔒 Basic
23

Protect a Login-Required Page

Confirm a logged-out request returns 401 and a logged-in one returns 200, via @login_required or LoginRequiredMixin. Redirect for web, return 401 for API, and avoid coverage gaps.

🔒 Basic

Chapter 5 — Defending Against Attacks (lessons 24–27)

Curb abuse with rate limiting, stop brute force with a lockout after repeated failures, and prepare for a leaked password with TOTP two-factor authentication. We finish with the mechanism that rotates the session ID on every login, and managing keys like SECRET_KEY through environment variables.

24

Curb Abuse with Rate Limiting

A RateLimiter counting only records from a recent time window. Confirm it allows 5, rejects the 6th, and recovers over time, plus real decisions on key, storage, and 429/Retry-After.

🔒 Basic
25

Stop Brute Force with a Lockout After Repeated Failures

Log failed and successful logins to LoginAttempt, reject even a correct password with 429 after 5 fails. Lockout scope, clearing, notifying, and keeping it from becoming an attack surface.

🔒 Basic
26

Add Two-Factor Authentication with TOTP

Two-factor auth adds a 6-digit app code (something you have) atop a password (something you know). Generating and verifying a secret with pyotp, QR codes, recovery codes, and clock-drift tolerance.

🔒 Basic
27

Rotating the Session ID and Managing Keys

Rotate the session ID on every login to prevent session fixation attacks. Reading SECRET_KEY and OAuth secrets from environment variables instead of hardcoding them, and rotating them if they leak.

🔒 Basic

Chapter 6 — Operations (lessons 28–30)

Triage "I can't log in" reports by cause, backed by an audit log that records who did what and when. We close out all 30 lessons by designing what account deletion erases and what it anonymizes and keeps.

28

Triage "Can't Log In" by Cause

diagnose_login mechanically finds the cause — unregistered, locked out, unverified email, or wrong password — from user state. A cause/response table, splitting diagnosis from the shown message.

🔒 Basic
29

Record Who Did What and When with an Audit Log

Record signups, failed and successful logins, and account deletion to AuditLog for later tracing. What to record and leave out, tamper protection and retention periods, and using it for detection.

🔒 Basic
30

What to Delete and Keep on Account Deletion

Delete the user on deletion, but keep a record in the audit log. Erase personal data but anonymize records the business needs, and choose soft deletion vs. cascading on_delete. A 30-lesson wrap-up.

🔒 Basic

Once you finish all 30 lessons, move on to Stripe Payments and Subscriptions, where you'll connect billing to the login you built. All courses unlock with a membership.