DRF authentication (Token, JWT) in Django - Step-by-Step Execution

Concept Flow - DRF authentication (Token, JWT)

Client sends login request

↓

Server verifies credentials

↓

If valid

→Generate Token or JWT

↓

Send JWT to client

↓

Send Token to client

↓

Client stores token/JWT

↓

Client sends requests with token/JWT

↓

Server checks token/JWT validity

↓

If valid

→Allow access

↓

Else deny access

This flow shows how a client logs in, receives a token or JWT, and uses it to access protected resources by sending it with requests.

Execution Sample

Django

from rest_framework.authtoken.models import Token
from rest_framework_simplejwt.tokens import RefreshToken
from django.contrib.auth import authenticate

# Token creation example
user = authenticate(username='user', password='pass')
if user:
    token, created = Token.objects.get_or_create(user=user)
    token_key = token.key

# JWT creation example
refresh = RefreshToken.for_user(user)
access_token = str(refresh.access_token)

This code shows how DRF creates a Token or JWT after user authentication.

Execution Table

Step	Action	Input	Output	Notes
1	Client sends login request	username='user', password='pass'	Request received	Client initiates login
2	Server verifies credentials	username='user', password='pass'	User object if valid	Authentication check
3	Generate Token	User object	Token string	DRF Token created
4	Generate JWT	User object	JWT access and refresh tokens	JWT tokens created
5	Send Token/JWT to client	Token or JWT	Token/JWT sent in response	Client receives tokens
6	Client stores token/JWT	Token/JWT	Stored in client storage	Ready for future requests
7	Client sends request with token/JWT	Token/JWT in header	Request received with token	Authentication header included
8	Server checks token/JWT validity	Token/JWT	Valid or invalid	Token verified
9	If valid, allow access	Valid token	Protected resource data	Access granted
10	If invalid, deny access	Invalid token	401 Unauthorized	Access denied

💡 Execution stops after access is granted or denied based on token validity.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	After Step 8	Final
user	None	User object if valid	User object	User object	User object	User object	User object	User object	User object
token	None	None	Token string	Token string	Token string	Token string	Token string	Token string	Token string
jwt_access	None	None	None	JWT access token	JWT access token	JWT access token	JWT access token	JWT access token	JWT access token
jwt_refresh	None	None	None	JWT refresh token	JWT refresh token	JWT refresh token	JWT refresh token	JWT refresh token	JWT refresh token
request_token	None	None	None	None	None	Token/JWT stored	Token/JWT sent with request	Token/JWT validated	Access granted or denied

Key Moments - 3 Insights

Why do we generate both access and refresh tokens in JWT?

Access tokens are short-lived for security; refresh tokens allow getting new access tokens without logging in again. See execution_table rows 4 and 5.

What happens if the token sent by the client is invalid or expired?

The server denies access and returns 401 Unauthorized, as shown in execution_table row 10.

Is the token created at login or on every request?

Token or JWT is created once at login (rows 3 and 4), then sent with each request (row 7) for validation.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at Step 3?

A Token string

B JWT access token

C User object

D 401 Unauthorized

💡 Hint

Check the 'Output' column for Step 3 in the execution_table.

At which step does the client send the token or JWT with a request?

A Step 2

B Step 5

C Step 7

D Step 9

💡 Hint

Look for 'Client sends request with token/JWT' in the execution_table.

If the token is invalid, what is the server's response according to the execution_table?

A Protected resource data

B 401 Unauthorized

C Token string

D User object

💡 Hint

Check the 'Output' column for Step 10 in the execution_table.

Concept Snapshot

DRF Authentication with Token and JWT:
- Client logs in sending credentials.
- Server verifies and creates Token or JWT.
- Token/JWT sent back to client.
- Client stores and sends token with requests.
- Server validates token to allow or deny access.
- JWT uses access and refresh tokens for security.

Full Transcript

This visual execution trace shows how Django REST Framework (DRF) handles authentication using Token and JWT methods. First, the client sends a login request with username and password. The server checks these credentials. If valid, the server creates either a Token or JWT (which includes access and refresh tokens). These tokens are sent back to the client, who stores them securely. For future requests, the client includes the token or JWT in the request headers. The server then validates the token. If the token is valid, the server grants access to protected resources. If invalid or expired, the server denies access with a 401 Unauthorized response. This process ensures secure, stateless authentication for API access.