Implicit отдавал access token прямо в URL после редиректа — он попадал в историю, логи, Referer и был доступен скриптам. Authorization code + PKCE: клиент получает одноразовый код, а обмен кода на токен подтверждает секретным code_verifier, хеш которого отправлен заранее.
А ещё Для SPA часто BFF: токены держит сервер, браузер — только cookie сессии
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
У публичного клиента — SPA или мобильного приложения — нет места, где безопасно хранить клиентский секрет, поэтому обычный authorization code flow был для них неприменим, и исторически использовали implicit. Его беда в том, что access-токен приходит во фрагменте URL: он оседает в истории браузера, в логах прокси и реферерах. PKCE решает задачу иначе: клиент генерирует случайный verifier, отправляет его хеш при запросе кода, а при обмене кода на токен предъявляет сам verifier — перехваченный код без него бесполезен. Поэтому в OAuth 2.1 implicit исключён, а authorization code с PKCE рекомендован всем клиентам, включая конфиденциальные.
Один верный вариант. Подумайте, потом откройте ответ.
Структура и валидация JWT, проблема отзыва, роли OAuth2 и authorization code flow, OIDC, и авторизация на уровне методов.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto