Используете ли токены для авторизации

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

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

Как отвечать

Начните с того, где и как вы это делали, и покажите устройство:

• типы токенов: непрозрачный (opaque) токен это случайная строка, её проверяют запросом к серверу авторизации (introspection). JWT самодостаточен: header.payload.signature в Base64URL, подпись проверяется локально по ключу;
• JWT не шифрует: payload читает кто угодно, поэтому паролей и персональных данных туда не кладут. Проверяют подпись, exp, iss, aud, а алгоритм берут из конфигурации сервера, а не из заголовка токена;
• access и refresh: короткий access на минуты и длинный refresh, который меняется при каждом использовании. Отзыв решают коротким сроком жизни, списком отозванных jti или opaque-токенами;
• стандарты: OAuth 2.0 и OpenID Connect, для SPA и мобильных Authorization Code с PKCE. Implicit и Password grant устарели;
• в Spring: Spring Security как Resource Server, spring.security.oauth2.resourceserver.jwt.issuer-uri или jwk-set-uri, ключи подтягиваются по JWKS. Роли из claims превращаются в GrantedAuthority через JwtAuthenticationConverter, дальше @PreAuthorize. Сервер авторизации свой (Spring Authorization Server) или внешний, например Keycloak.

Про клиент: токен в localStorage доступен любому XSS, поэтому в браузере надёжнее HttpOnly-cookie с Secure и SameSite плюс защита от CSRF или схема BFF, где токены до браузера не доходят.

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

Называют JWT зашифрованным и кладут в него лишнее. Base64URL это кодирование, payload декодируется за секунду.

Проверяют JWT руками: парсят строку, забывают про подпись или принимают alg: none. В Spring это уже сделано, и самописный фильтр чаще добавляет дыру, чем закрывает.

Выдают access-токен на сутки и дольше без механизма отзыва. Украденный токен тогда действует до конца срока, и остановить его нечем.