В настоящее время все поставщики OAuth, такие как Okta, OAuth0, Firebase auth и т. Д. c. предлагаем использовать поток PKCE для приложений SPA и хранить токены доступа и обновления sh в локальном хранилище или объектах в памяти. Это допускает возможность XSS-атаки. Чтобы избежать возможности такого рода атак, обычно предлагается одна рекомендация - вообще не хранить токены на стороне клиента, а вместо этого хранить их на стороне сервера.
Я знаю, что это можно реализовать с помощью session_id cook ie, но похоже, что в этом случае нет необходимости использовать токен JWT, поскольку у вас уже есть информация о пользователе на стороне сервера (возможно, JWT может использоваться в случае, если у вас есть архитектура микросервисов и вы храните информацию о пользователе в своем прокси / шлюзе, чтобы при передаче session_id cook ie вы могли получить токен JWT из внутреннего хранилища и ввести JWT в свой запрос и передать его через микросервисы ).
Итак, мне интересно, есть ли какие-либо передовые методы для создания этого типа авторизации и аутентификации, и является ли это широко используемым подходом, или большинство служб предпочитают хранить токен на стороне клиента и прилагать некоторые усилия для уменьшения возможности XSS атаки? Возможно также есть несколько примеров того, как такие сервисы, как StackOverflow, Medium и др. c. реализовать этот процесс, потому что я не вижу токенов в локальном хранилище этих веб-сайтов.