В чем была сложность проекта системы доступа

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

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

Как отвечать

Возьмите одну-две настоящие сложности и расскажите по схеме: контекст, проблема, варианты, решение, результат. Типичные трудности систем доступа, на которые можно опереться, если они у вас были:

• модель прав: RBAC перестаёт хватать, когда доступ зависит от атрибутов (отдел, владелец объекта, время). Решения: ABAC или ReBAC по модели Zanzibar (OpenFGA, SpiceDB), политики в OPA или Casbin;
• отзыв доступа: JWT нельзя отозвать до истечения срока. Отсюда короткий срок жизни access-токена, ротация refresh-токенов и список отозванных в Redis;
• производительность: права проверяются на каждый запрос. Кэш разрешений со сбросом при смене ролей, фильтрация на уровне запроса к базе, а не в Python после выборки;
• интеграция: единый вход через OIDC (Keycloak, корпоративный AD через LDAP), для SPA поток Authorization Code с PKCE;
• аудит: кто, когда и на каком основании получил доступ, неизменяемый журнал, требования 152-ФЗ при персональных данных;
• стек: в Django django-guardian для прав на объекты, в FastAPI проверка прав через Depends, PyJWT или authlib для токенов.

Если речь о физическом доступе (СКУД), сложности другие: работа контроллеров без связи с сервером, синхронизация пропусков, протоколы оборудования.

Детали должны быть из вашего проекта: число пользователей и ролей, время проверки прав, сколько сервисов подключили. Если отвечали за часть, говорите про неё. Если такого проекта не было, не сочиняйте: расскажите о самой сложной задаче с авторизацией, которая была.

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

Рассказывают о проекте в целом и не называют ни одной проблемы, которую решили лично.

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

Называют OAuth 2.0 протоколом аутентификации. OAuth 2.0 про делегирование доступа, аутентификацию поверх него даёт OpenID Connect.