Какой опыт работы с авторизацией был?

Что проверяют

Различаете ли вы аутентификацию и авторизацию и понимаете ли, где в Python-приложении проходит проверка прав. Следом обычно спрашивают, как отозвать JWT до истечения срока и как вы защищали доступ к чужим объектам.

Как отвечать

Сначала одной фразой разведите термины: аутентификация отвечает на вопрос «кто это», авторизация на вопрос «что ему можно». Отсюда разные коды: 401, если пользователь не опознан, 403, если опознан, но прав нет.

Дальше конкретика по вашему стеку:

• Django и DRF: сессии из коробки, для API permission_classes с IsAuthenticated и собственными классами, где has_object_permission проверяет доступ к конкретной записи. JWT в DRF не встроен, его дают пакеты вроде djangorestframework-simplejwt;
• FastAPI: зависимости через Depends, OAuth2PasswordBearer для извлечения токена, проверка ролей или scopes отдельной зависимостью на роуте;
• JWT: подпись, обязательная проверка exp и алгоритма, короткий access-токен и refresh-токен с ротацией. Отозвать выданный JWT без хранилища нельзя, поэтому держат список отозванных jti или версию токена у пользователя;
• OAuth 2.0 и OpenID Connect: вход через внешнего провайдера это OIDC поверх Authorization Code, для публичных клиентов с PKCE;
• пароли: медленные хэши, в Django по умолчанию PBKDF2, как альтернатива Argon2 или bcrypt. Быстрые MD5 и SHA-256 для паролей не годятся даже с солью.

Модель прав назовите явно: RBAC по ролям или проверка владельца объекта. Приведите свой пример, где такая проверка закрыла реальную дыру или где вы её добавили.

Где спотыкаются

Проверяют только факт входа, но не владельца объекта. Запрос /orders/42 отдаёт чужой заказ, это классическая уязвимость IDOR.

Кладут токен в localStorage и не думают об XSS, либо переносят его в cookie и забывают про HttpOnly, Secure, SameSite и защиту от CSRF.

Называют JWT «сессией без состояния» и не могут ответить, что делать, если токен украли. Без короткого срока жизни и механизма отзыва это открытая дверь на весь срок действия.