Как пользователь проходит аутентификацию и авторизацию при взаимодействии мобильного приложения с бекендом

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

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

Как отвечать

Начните с разделения: аутентификация отвечает на вопрос «кто это», авторизация на вопрос «что ему можно». Дальше опишите поток:

• вход: стандарт для мобильных клиентов это OAuth 2.0 Authorization Code с PKCE. Приложение открывает страницу входа в системном браузере (Custom Tabs, ASWebAuthenticationSession), а не во встроенном WebView, и меняет полученный код на токены. Мобильное приложение это публичный клиент: client_secret из APK достают за минуты, поэтому без PKCE нельзя;
• токены: короткий access token на минуты и долгий refresh token. Refresh на сервере хранится хэшем, при каждом использовании выдаётся новый, а повторное предъявление старого отзывает всю цепочку;
• хранение на устройстве: Android Keystore и Keychain на iOS, не открытые настройки;
• проверка на бэкенде: в Spring Boot это spring-boot-starter-oauth2-resource-server, JwtDecoder проверяет подпись по JWKS и поля exp, iss, aud. API работает без серверной сессии (SessionCreationPolicy.STATELESS), CSRF для токена в заголовке не нужен;
• авторизация: роли и scope из токена становятся GrantedAuthority, правила задаются в SecurityFilterChain через authorizeHttpRequests и в @PreAuthorize. Отдельно проверяется владение объектом: пользователь с ролью USER читает только свои заказы.

Сервером авторизации обычно служит Keycloak или Spring Authorization Server, свой писать не нужно.

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

Говорят, что JWT зашифрован. Обычный JWT только подписан, его payload читается любым Base64URL-декодером, секреты туда класть нельзя.

Считают выходом удаление токена на телефоне. Access token живёт до exp, поэтому на сервере отзывают refresh token, а для мгновенной блокировки держат короткий срок жизни или список отозванных jti.

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