centum

очень легко мыслить токенами, как сессией, но токен это не сессия, не стоит путать.
Токены используют как раз для того чтоб отойти от классической схемы с сессиями/паролями.
по порядку:
1) смотрите у вас есть сервис, состоит например из 10 серверов, которые отвечают за разные части функционала, поскольку функционал коммерческий вам нужно проверять каждый запрос от пользователя есть ли у него права для этого запроса.
вы вынуждены сделать единый сервер валидации, и с каждого своего сервера, для каждого запроса, запрашивать на сервере валидации проверку пользователя и его прав.
в такой ситуации сервер валидации для вашего сервиса становиться бутылочным горлышком, и мешает горизонтальной масштабируемости.
и абсолютно без разницы валидируете вы пользователя по паролю, айпи, или токену, сессии, схема одна и таже, производительность тоже одна и таже (именно поэтому нет никакого смысла менять сверку пользователя вместо пароля на сверку по айпи, или токену, или сессию, тем более понятно почему использования айпи в этой схеме просто глупая идея).

поэтому есть задача отойти от этой схемы, для возможности простого горизонтального масштабирования, для этого вы берёте информацию о пользователе (например его айди, права, и тд) и зашифровываете эти данные, и передаёте пользователю в виде токена.
2) На каждом вашем сервере есть алгоритм быстрой расшифровки, который на лету проверяет токены, и из него получает нужную информацию, о правах и айди пользователя (валидирует пользователя, без бутылочного горлышка), сами токены временные, в них также вшивают информацию о времени его действия, обычно в районе пары часов/суток, после чего вы перегенерируете токен заново (ключ для перегенерации и получения нового токена также вшиваете в токен, осуществляя непрерывность процесса перегенерации токенов).
3. Что делать если пользователь поменял пароль?
ничего - токен даёт пользователю право на вход, и не имеет значения какой у пользователя пароль.

Всем хорош Django, все у него есть, но...
Django - это коробочный продукт, со всеми достоинствами и недостатками, присущими коробочным продуктам. То есть внутри большой коробки, называемой Django, есть много других коробочек, содержимое которых прекрасно состыковано с самим продуктом и с другими коробочками. Поэтому разработчик на Django чувствует себя вольготно. А если у него возникает проблема, то большое комьюнити всегда поможет.
Я разработал на Django только один проект. Возможно, будь проект простым, я до сих пор бы использовал Django. Но проект оказался неожиданно сложным. Написание кода для обработки данных из некоторого количества таблиц с довольно запутанными связями показало мне, что у Django, несмотря на его популярность, совершенно никудышный ORM. Используя Django, я половину обращений к таблицам реализовывал в чистом SQL, а затем стыковал результаты с данными полученными с помощью ORM. У меня все получилось. Но осадок остался. Поэтому следующую версию того же проекта, и все последующие тоже, я написал на Flask, используя в качестве ORM небезызвестный SQLAlchemy.
Я не жалею времени, потраченного на изучение Django. Это хороший опыт. Те, кто используют Django, чувствуют себя защищенными. Они часть большого дружного сообщества, где можно найти любую поддержку.
Но я также не жалею, что я ушел от Django. У Django вся магия ( регистрация, авторизация, работа с сессиями и многое-многое другое) спрятана под капотом, я просто подключал компоненты и использовал их. Используя Django, я делал многие вещи автоматически, совершенно не задаваясь вопросом как эти вещи работают. Уйдя от Django, я лучше стал понимать то, чем занимаюсь каждый день.
Можете мне поверить на слово, на Flask-е возможно писать очень большие проекты, с большим количеством кода. При этом реализация всей магии ложится на Вас. Это просто вопрос доверия. Используя Django, Вы доверяете всю магию Django, не используя его, Вы доверяете всю магию себе.