DEV Community: Ubaid Ullah

JWT Authentication in Django: Fix 'Invalid Token' and Token Expired 401 Errors

Ubaid Ullah — Sat, 10 Oct 2026 08:20:16 +0000

Originally published on djangix.com

JWT authentication in Django usually breaks in a very specific way: login succeeds, you copy the access token, and the very next request comes back with 401 Unauthorized. The response body is the whole diagnosis — if you read it before changing code, this is a ten-minute fix instead of an afternoon of guessing.

The short answer is this: a Simple JWT 401 almost always means one of four things. The access token has expired, the wrong token (a refresh token) was sent to an API endpoint, the Authorization header never reached Django, or the token was signed with a different secret than the server now uses. Below is how to tell which one you have, and the correct fix for each.

What the JWT authentication error actually says

Django REST Framework with Simple JWT returns a JSON body, not just a status code. Read the detail, code, and the per-message fields:

{
  "detail": "Given token not valid for any token type",
  "code": "token_not_valid",
  "messages": [
    {
      "token_class": "AccessToken",
      "token_type": "access",
      "message": "Token is invalid or expired"
    }
  ]
}

That one body already narrows the problem down:

code token_not_valid, message Token is invalid or expired: the token failed validation — it is expired, malformed, blacklisted, or signed with a different key. Check the steps below in order.
detail Authentication credentials were not provided: this is a different bug. No usable Authorization header reached the view at all, so Django never even saw a token. Skip to the header check below.
detail Given token not valid for any token type, with a valid-looking token: you very often sent the refresh token where an access token belongs. The two token types are not interchangeable.
Token is blacklisted: the refresh token was already rotated or logged out. The client must log in again — no server-side setting will resurrect that token.

JWT authentication settings that cause most 401 errors

Most production 401s are configuration, not code. This is a known-good baseline for Simple JWT 5.5.1, the current release on PyPI at the time of writing:

# settings.py
from datetime import timedelta

INSTALLED_APPS = [
    # ...
    "rest_framework",
    "rest_framework_simplejwt.token_blacklist",
]

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        "rest_framework_simplejwt.authentication.JWTAuthentication",
    ),
    "DEFAULT_PERMISSION_CLASSES": (
        "rest_framework.permissions.IsAuthenticated",
    ),
}

SIMPLE_JWT = {
    "ACCESS_TOKEN_LIFETIME": timedelta(minutes=15),
    "REFRESH_TOKEN_LIFETIME": timedelta(days=7),
    "ROTATE_REFRESH_TOKENS": True,
    "BLACKLIST_AFTER_ROTATION": True,
    "AUTH_HEADER_TYPES": ("Bearer",),
}

Three settings in that block explain most surprises:

Short default access lifetime: out of the box, Simple JWT access tokens live for five minutes and refresh tokens for one day. If your frontend never calls the refresh endpoint, every user appears to be logged out after five minutes. That is expiry working as designed, not a bug.
Signing key follows SECRET_KEY: by default tokens are signed with your Django SECRET_KEY. Regenerate or change SECRET_KEY in production and every existing token instantly becomes invalid. Users must log in again, and no code fix changes that.
The blacklist app must be installed: if you enable blacklist-after-rotation without adding the token_blacklist app and running migrations, rotation breaks. Install the app, migrate, then enable the setting.

Wire the endpoints once, in your root URL configuration:

# urls.py
from django.urls import path
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
    TokenVerifyView,
)

urlpatterns = [
    path("api/token/", TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path("api/token/refresh/", TokenRefreshView.as_view(), name="token_refresh"),
    path("api/token/verify/", TokenVerifyView.as_view(), name="token_verify"),
]

Fix JWT token expired errors with a real refresh flow

Expired access tokens are normal. The bug is a client that treats expiry as a logout instead of refreshing once and retrying the original request:

async function apiFetch(url, options = {}) {
  const makeRequest = (access) => fetch(url, {
    ...options,
    headers: {
      ...(options.headers || {}),
      Authorization: `Bearer ${access}`,
    },
  });

  let response = await makeRequest(localStorage.getItem("access"));
  if (response.status !== 401) return response;

  const refreshResponse = await fetch("/api/token/refresh/", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ refresh: localStorage.getItem("refresh") }),
  });
  if (!refreshResponse.ok) return response; // refresh is dead: log the user out

  const data = await refreshResponse.json();
  localStorage.setItem("access", data.access);
  if (data.refresh) localStorage.setItem("refresh", data.refresh);
  return makeRequest(data.access);
}

Note the two details people miss. First, with rotation enabled the refresh response can contain a new refresh token — store it, or the next refresh will present a blacklisted token. Second, only retry on 401, and only once. Retrying in a loop turns a dead session into a request storm.

Still not sure whether the token itself is the problem? Inspect it server-side before blaming the frontend:

from rest_framework_simplejwt.tokens import AccessToken

token = AccessToken("paste-the-access-token-here")
print(token["token_type"])  # must be "access"
print(token["user_id"])
print(token["exp"])         # UTC epoch seconds: compare with your server clock

If constructing the token raises an error, the token is malformed or signed with another key. If it parses but the exp value is in the past, it is simply expired and the refresh flow above is the fix. Also check server time: a container or VM with a skewed clock will reject fresh tokens as not yet valid or already expired.

One related trap: a browser can drop the Authorization header before Django ever sees it. If your API and frontend are on different origins and preflight requests fail, treat it as a CORS problem first — see our guide to being blocked by the CORS policy. And do not confuse this with cookie-session failures: header-based JWT auth does not need a CSRF token, which is a separate mechanism covered in our post on Django CSRF verification failed. Verifying a credential before trusting it is the same discipline we apply to webhooks in our Stripe webhook verification guide.

The wrong fixes for invalid token errors

These appear in almost every forum thread, and each one trades a small bug for a bigger one:

Stretching the access token lifetime to 30 days: the 401s stop, but a stolen access token now works for a month and cannot be revoked. Keep access tokens short and fix the refresh flow instead.
Turning off expiry checks or adding a huge leeway: a large LEEWAY setting hides clock problems for a while and quietly accepts tokens that should be dead.
Commenting out IsAuthenticated to make the error go away: the endpoint now works for everyone, including people with no token at all. You have removed the lock, not fixed the key.
Regenerating SECRET_KEY every deploy: every deploy logs out every user and invalidates every token, because the signing key changed. Keep SECRET_KEY stable in your environment, and rotate it only as a deliberate, communicated event.
Sending whichever token is at hand: access and refresh tokens have different token_type claims and different jobs. An endpoint that expects an access token will correctly reject a refresh token every time.

Final checklist for JWT authentication in Django

Work through these in order and the 401 will name itself:

Read the response body first: token_not_valid, credentials not provided, and blacklisted tokens are three different bugs with three different fixes.
Confirm the token type: decode the token and check that token_type is access for API calls.
Check expiry and server time: compare the exp claim with a correct UTC clock on the server.
Verify the header arrives: confirm the Authorization Bearer header reaches Django, through your proxy and CORS configuration.
Keep SECRET_KEY stable: if it changed, old tokens are invalid by design and users must log in again.
Implement refresh properly: refresh once on 401, store any rotated refresh token, retry the original request once, and log out cleanly if the refresh token is rejected.

Do that, and JWT authentication stops being a mystery error and becomes what it should be: a short-lived access token, a working refresh flow, and a 401 you can explain in one sentence.

SaaS Product Development: From Idea to Launch, Step by Step

Ubaid Ullah — Fri, 09 Oct 2026 06:52:32 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

Building a SaaS product is less a single build than a sequence of decisions. Doing them in the wrong order is what makes projects expensive, according to the original article.

The sequence, summarised

Validate the problem first. Talk to the people who would pay, and confirm the pain is frequent and costly enough to justify software.
Define the smallest useful version. Separate the core workflow that must work on day one from everything that can wait.
Design around the workflow, not features. Map the main user journey end to end before screens multiply.
Choose boring, proven foundations. Accounts, payments and data separation are not places to experiment.
Build in visible slices. Working software shown regularly beats a long silent build with a big reveal.
Prepare for launch as its own step. Billing checks, backups, monitoring and a support path need attention before users arrive, not after.
Plan the post-launch loop. Early feedback, fixes and small improvements are part of development, not a separate phase.

The recurring theme: each stage reduces the risk of the next, and skipping early stages simply moves their cost later, with interest.

Read the full article on Djangix: SaaS Product Development: From Idea to Launch, Step by Step — with the complete step-by-step process and what happens at each stage.

API Integration Services: What They Include, What They Cost, and When You Actually Need Them

Ubaid Ullah — Fri, 09 Oct 2026 06:52:13 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

If staff are copying information between systems by hand, you are already paying for an integration — in hours, errors and delays. The original article explains what a proper integration service actually covers.

What is usually included

Discovery and mapping: Which systems hold which data, what should move where, and in which direction it should flow.
Building the connection: Authentication, data transformation, and the scheduled or event-driven movement itself.
Error handling and visibility: Retries for temporary failures, alerts when something breaks, and logs a non-developer can check.
Testing and handover: Checking edge cases such as duplicates and missing fields, plus documentation so the integration is not a mystery box.

Cost and need, in brief

The article frames cost around complexity — number of systems, quality of their documentation, and how critical real-time movement is. Simple, well-documented connections sit at one end; fragile or poorly documented systems at the other. You probably do not need a custom integration when a platform already offers a maintained built-in connector that does exactly what you need.

A useful test: if the manual copying is frequent, error-prone and growing with the business, an integration usually pays for itself; if it is rare and stable, leave it alone.

Read the full article on Djangix: API Integration Services — with cost drivers, examples and the build-vs-built-in decision.

How to Choose a SaaS Development Company: 9 Questions That Save You Money

Ubaid Ullah — Fri, 09 Oct 2026 06:51:50 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

Choosing the wrong builder for a SaaS product is expensive twice: you pay for the first build, then pay again for the rebuild. The original article turns the decision into questions you can ask before signing.

The themes behind the nine questions

Relevant proof: Has the company shipped SaaS products — with subscriptions, accounts and ongoing users — or only brochure sites and demos?
Who actually builds it: Will the people you met do the work, and how is the project staffed if someone leaves?
How billing and accounts are handled: SaaS-specific experience matters in areas like recurring payments, permissions and multi-user data separation.
Communication and visibility: How often will you see working software, and how are delays or scope changes surfaced?
Ownership and exit: Do you own the code, infrastructure accounts and documentation, so you are not locked in?
After launch: What does support look like once real users arrive — fixes, monitoring and small improvements?
Pricing clarity: What is included, what is assumed, and what triggers extra cost?

Score answers consistently across candidates, be wary of answers that stay vague when you ask for examples, and prefer a small paid discovery over a large leap of faith.

Read the full article on Djangix: How to Choose a SaaS Development Company — with all nine questions and the red flags for each.

What Does an AI Automation Agency Actually Do? (Process, Projects, Costs)

Ubaid Ullah — Fri, 09 Oct 2026 06:51:27 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

The label sounds grand, but the day-to-day work is practical: find a repetitive process, connect the tools involved, add AI only where it genuinely helps, and keep a person in charge of the outcome.

What a typical engagement looks like

Audit first. Map where time is actually lost, check the quality of the underlying data, and pick one workflow with a measurable payoff.
Build a scoped project. Common examples include document handling, enquiry follow-up, internal search over company material, and reporting assembled from existing systems.
Deliver with guardrails. Outputs that affect customers or money start as drafts or recommendations for human approval, with logging so mistakes can be traced.
Support after launch. Models, tools and processes change, so monitoring and small adjustments are part of the service, not an afterthought.

About cost and fit

Pricing in the original article is framed around scope: a single workflow is a very different budget from a multi-system programme. The honest test is whether the time and error cost of the manual process clearly exceeds the cost of automating it. And sometimes the right answer is that you do not need an agency at all — a built-in feature of a tool you already pay for may cover the need.

Read the full article on Djangix: What Does an AI Automation Agency Actually Do? — with project examples, process detail and cost ranges.

Stripe API Integration for SaaS: Connect Payments Without the Usual Mistakes

Ubaid Ullah — Fri, 09 Oct 2026 06:51:06 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

Adding payments to a SaaS product looks simple until the first edge case: a card fails after access was granted, a customer is charged twice, or a cancellation never reaches your database. The original article treats billing as a state problem, not just a checkout form.

The core sequence, in my summary

Model billing in your own data first. Keep the customer and subscription identifiers and the current status on your side, so your product does not depend on a live call to decide who has access.
Use a hosted checkout for the first version. It handles card collection, common payment methods and compliance scope far better than a custom form built quickly.
Let server-side events drive access. Payment and subscription changes should update your records from verified notifications arriving at your server — not from what the browser reports after redirect.
Handle the awkward lifecycle events. Failed renewals, cancellations, plan changes and refunds each need an explicit response in your access logic, tested in advance.
Make retries safe. Repeating a create call after a timeout should not create a second charge — use the provider's idempotency mechanism and test that path.
Test with simulated events before going live, including the failure cases, using separate test and live credentials carefully.

Mistakes to avoid

Granting access from an unverified browser redirect, burying billing failures where support cannot see them, and assuming the happy path covers renewals. Most billing bugs are lifecycle bugs.

Read the full article on Djangix: Stripe API Integration for SaaS — with the full architecture, event list and common-mistakes checklist.

AI Automation for Small Business: 7 Workflows Worth Automating First

Ubaid Ullah — Fri, 09 Oct 2026 06:50:45 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

A small business rarely needs a grand AI strategy first. It needs one repetitive workflow given back. The original article picks seven starting points and explains, for each, what it does and where human judgement should stay.

The seven, summarised

Lead capture and follow-up — record new enquiries automatically and make sure first responses and reminders do not depend on someone remembering.
Inbox triage and reply drafts — sort incoming mail by topic and urgency and draft answers for a person to approve, rather than sending unchecked.
Quotes and invoices from job details — turn the details you already collect into consistent documents, and chase late payment politely and automatically.
Reviews and referrals — ask at the right moment after a job and route unhappy responses to a human quickly.
FAQ answers on your site — a grounded assistant trained on your own material for the questions customers repeat.
Reports from data you already have — regular summaries assembled from your existing systems instead of manual copying.
Data entry between systems — move information you currently re-type from one tool to another.

Rules that keep it useful

Start with work that is high-volume, repetitive and easy to check. Keep a human approving anything financial, sensitive or irreversible at first, measure the time actually saved, and expand only after the first workflow is trusted. Some work — nuanced complaints, judgement calls, relationships — should stay human.

Read the full article on Djangix: AI Automation for Small Business: 7 Workflows Worth Automating First — with setup and cost notes for each workflow.

Custom Software Development Companies: How to Compare Them Before You Hire

Ubaid Ullah — Fri, 09 Oct 2026 06:50:19 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

Most vendors sound identical on a sales call: similar stacks, similar timelines, similar promises. The useful differences appear when you ask for evidence and look at the terms around the work.

A practical way to compare

Match the portfolio to your problem. A proof-of-concept or a demo is not the same as a shipped system handling real users. Ask whether the firm has actually delivered something like what you need.
Pin down code ownership and access from day one. Who owns the code, the repository and the documentation? Can someone else take over if the relationship ends?
Ask how communication really works. How often are demos, how fast are answers, and who is accountable when a deadline slips or a scope question appears?
Make pricing comparable. Is the quote fixed, time-based or staged? What is explicitly excluded, and what happens when assumptions change?

Trade-offs worth naming

A large agency can bring a broader bench but also more overhead and layers. A boutique team can be closer and faster, but capacity is narrower. In-house hiring gives control but is the slowest and most expensive path to assemble. None is automatically best — fit matters.

A simple process

Score the same criteria for every candidate, run a short discovery before committing to a full build, verify claims with references or shipped work, and let that evidence drive the choice — not the polish of the proposal.

Read the full article on Djangix: Custom Software Development Companies: How to Compare Them Before You Hire — with the full scorecard and final checklist.

select_related vs prefetch_related: The Django N+1 Fix, Explained With Query Counts

Ubaid Ullah — Fri, 09 Oct 2026 06:49:57 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

A Django page that feels instant with a handful of rows can crawl once the table grows. Often the cause is not the database itself, but how many separate trips the ORM makes to it.

The N+1 pattern, in plain terms

Fetch a list in one query, then follow a related object for each row — and each follow-up is another query. Ten rows hide the problem; a thousand rows turn it into a thousand extra trips.

Choosing the right tool

For a single-valued relationship — such as the one author of an article — fetch the related row together with the main row in a joined query. One trip, and later attribute access is free.
For a collection — such as all the comments or books belonging to each item — fetch the related rows in a separate batched query and match them in Python. Trying to join collections into the main query can multiply rows and repeat the parent data.

That direction — single-valued versus collection — is the core decision rule in the original article.

Useful variations the full article covers

Following a chain of single-valued relationships in one call.
Restricting a prefetch to only the rows you need, for example only visible comments, and storing that filtered result under a custom attribute.
Prefetching through a relationship into a deeper related collection.

Habits that keep you honest

Count queries in tests and development rather than guessing — an assertion on query count catches regressions when a template starts touching a new relation.
Watch what your templates and serializers actually access; the fix belongs where the access happens.
Remember the limits: these helpers do not remove queries for later, separate querysets, and joining a collection can bloat results.

The short version: measure the query count, match the helper to the shape of the relationship, and re-check after you change it.

Read the full article on Djangix: select_related vs prefetch_related: The Django N+1 Fix — with worked examples and the query count at each step.

Content Security Policy Blocking Your Scripts? Fix "Refused to Execute Inline Script" Properly

Ubaid Ullah — Fri, 09 Oct 2026 06:49:23 +0000

Originally published on the Djangix blog. This is a condensed version — the full article is linked at the end.

You add a Content Security Policy, deploy, and the site looks fine but nothing responds. That is not the policy failing — it is the policy working. Your own inline code simply is not allowed yet.

What the policy is doing

CSP is a browser-enforced allowlist for scripts, styles, images and connections. Its main security value is against injected scripts, and injected code is usually inline — so a strict policy blocks inline code by default, including yours.

Five fixes, in the order to try them

Move inline code to external files. This is the fix the policy is pushing you toward. A script file served from your own origin is already allowed by a self-only script rule, and it also gains caching and linting.
Use a fresh nonce for code that must stay inline. Some per-page configuration has to be rendered inline. Generate a random value for every response, put the same value in the policy and the tag, and never reuse it.
Hash a script that never changes. A fixed snippet can be allowed by its hash — but any edit, even formatting, changes the hash and blocks it again.
Replace inline handlers with listeners. Attributes such as click handlers in markup are blocked, which is why pages can load while buttons do nothing. Move the behaviour into JavaScript and attach listeners there.
Name third parties explicitly. Analytics, chat and embeds each need their own origins listed in the relevant directives. Do not use a wildcard — that also allows an attacker's origin.

The shortcut to avoid

Allowing inline scripts generally makes the errors disappear by disabling the protection CSP exists to provide. If that is the fix, the policy is mostly decoration.

Safer rollout

Start in report-only mode: the browser enforces nothing but reports violations, so you can find and fix real usage before enforcing the same policy for users.

Read the full article on Djangix: Content Security Policy Blocking Your Scripts? — including the Django nonce middleware example and the full ranked fixes.

Streaming OpenAI API Responses: How It Works, in Python, Django & FastAPI

Ubaid Ullah — Fri, 09 Oct 2026 06:48:36 +0000

Originally published on the Djangix blog. This is a condensed version — the full article, with complete code, is linked at the end.

A non-streamed chat answer leaves the user staring at a spinner for the whole generation. Streaming changes the feel, not the total time: the first tokens arrive in under a second and the answer appears to type itself.

What is actually sent

The transport is Server-Sent Events — one HTTP response that stays open and delivers small data: messages. Each message carries a JSON chunk, and the useful text lives in a tiny delta field. Most chunks are fragments, not whole words, so the client simply concatenates them until a final done marker arrives.

Going through your own backend

Browsers should not call the provider directly, because that would expose your API key. So your server receives the chunks and re-emits them — and that middle step is where many implementations break.

Wrap each token as JSON. Raw token text can contain newlines, which break the event framing. Encoding the token inside a JSON object avoids mangled multi-line answers.
Read with fetch, not EventSource, for POST chats. The built-in event API cannot send a JSON body or an authorization header, so read the response stream manually and keep a buffer for events split across network chunks.
Ask for usage explicitly. In the example in the full article, a stream option is needed if you want a final usage chunk for billing or budgeting.

Production pitfalls worth planning for

Buffering proxies: Reverse proxies and CDNs may hold the response and deliver it all at once, silently defeating streaming. Disable buffering for that route and test through the real production path.
Errors after the stream starts: Once the first chunk is sent, you cannot change the status code. Send an error as an event instead and render it in the UI.
Disconnected users and saving: Stop consuming when the client goes away, and save the assembled answer once at the end rather than writing to the database per token.
Idle timeouts: Periodic keepalive comments can keep a long generation from being cut off.

When not to stream

Short answers gain little, machine-consumed structured output usually needs to be complete before it can be parsed, and background jobs have no one watching. Streaming is a user-experience feature — use it where a person is waiting.

Read the full article on Djangix: Streaming OpenAI API Responses: How It Works, in Python, Django & FastAPI — with the complete Python, Django StreamingHttpResponse and FastAPI StreamingResponse code.

Building SafetyGraph: 546,891 Industrial Incident Records in One Queryable Dataset

Ubaid Ullah — Fri, 09 Oct 2026 06:42:15 +0000

Originally published on the Djangix blog: Building SafetyGraph: 546,891 Industrial Incident Records in One Queryable Dataset

Public industrial safety records in the US are rich and, historically, painful to use: the same underlying information has been spread across separate agency systems, each with its own search form and export quirks, and much of it reachable only one lookup at a time. SafetyGraph, the project described in the full article, brings those records together into one queryable dataset of more than half a million incidents.

The interesting engineering is less about scraping pages than about identity. Records describing the same company appear under spelling variants, punctuation differences, and changed names, so the pipeline normalises names, pairs likely matches conservatively, and builds explicit relationships between establishments, inspections, violations, and accidents instead of leaving users with a pile of disconnected rows.

With that structure in place, questions that once meant hours of manual cross-referencing become a single query: show a company's history across sources, or follow the chain from an inspection to what it found and what happened next. The dataset is positioned for safety teams, researchers, journalists, and builders who need that history in a form software can actually use.

The full article explains where the records come from, how the matching and linking work, what the resulting data model looks like, and what you can ask it on day one.

Full article: Building SafetyGraph: 546,891 Industrial Incident Records in One Queryable Dataset