Как устроена авторизация в приложении

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

Различаете ли вы аутентификацию и авторизацию и знаете ли, как это собрано в Spring Security: где проверяется токен, где хранятся права, на каком уровне принимается решение. Следом обычно спрашивают, как не пустить к чужим данным по подменённому id и как отозвать JWT.

Как отвечать

Аутентификация отвечает на вопрос «кто вы», авторизация на вопрос «что вам можно». В Spring Security 6 это цепочка фильтров:

• SecurityFilterChain: бин с конфигурацией, WebSecurityConfigurerAdapter из старых статей удалён. Правила по URL задаются через authorizeHttpRequests и requestMatchers;
• SecurityContextHolder: после входа в контексте лежит Authentication с набором GrantedAuthority. Роль это authority с префиксом ROLE_, поэтому hasRole("ADMIN") ищет ROLE_ADMIN;
• сессии: JSESSIONID и сессия на сервере, при нескольких инстансах через Spring Session в Redis. Выход и отзыв тут простые;
• JWT: сервис работает как resource server, проверяет подпись токена по ключам из JWKS провайдера (например, Keycloak) и берёт роли из claims. Отзыв сложнее: короткий срок жизни access-токена, ротация refresh-токена, при необходимости стоп-лист по jti;
• методы: @EnableMethodSecurity и @PreAuthorize("hasRole('ADMIN')") на сервисе, для сложных правил свой бин в выражении или PermissionEvaluator;
• пароли: только через PasswordEncoder, по умолчанию DelegatingPasswordEncoder с bcrypt.

Отдельно скажите про проверку владельца: роль говорит, что пользователь может читать заказы, но не какие именно. Условие «заказ принадлежит текущему пользователю» проверяется в сервисе или прямо в запросе к базе.

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

Проверяют только роль и забывают про объект. Пользователь меняет id в URL и видит чужие данные, это одна из самых частых уязвимостей API.

Пишут свой JWT-фильтр с секретом в коде и catch (Exception e) вокруг разбора. Надёжнее готовый resource server и ключи вне репозитория.

Выключают CSRF «потому что мешает». Для API с токеном в заголовке это оправдано, для cookie-сессий это открытая дыра.