Настройка
Мы создаем PWA (прогрессивное веб-приложение). Основными компонентами являются оболочка приложения (SPA) и API. REST API предоставит данные, необходимые для приложения, а SPA обработает все остальное ( согласно рекомендации Google ).
Проблема
Аутентификация конца -user кажется проблематичным c, потому что веб-браузер должен быть учтен. Мы хотим, чтобы вход в систему сохранялся после закрытия браузера. Мы провели исследование о возможных путях решения этой проблемы, однако мы хотели бы убедиться, что мы не идем в неправильном направлении.
Решения, которые мы рассмотрели
Сеансовая аутентификация - пользователь отправляет имя пользователя и пароль в / account / auth и получает только HTTP-запрос Cook * ie с идентификатором сеанса. Сессия должна быть сохранена в базе данных или Redis. Проблема с этой опцией заключается в том, что куки автоматически отправляются браузером, поэтому нам нужна защита от CSRF. При использовании Pattern Token Synchronizer новый токен будет генерироваться каждый раз, когда делается запрос на изменение состояния, например, POST. Это означает, что приложению необходимо предоставлять токен CSRF при каждом запросе, чтобы PWA мог отправить его через AJAX. Мы определили, что это не идеально, поскольку пользователь может отправить несколько почтовых запросов в быстрой последовательности , что приводит к сбою некоторых из них и ухудшению качества работы пользователя.
Мы также можем использовать этот метод без CSRF, ограничивая политику CORS одним и тем же доменом и добавляя требование заголовка, которое технически должно остановить всю CSRF, однако мы не уверены, насколько это будет безопасно.
Аутентификация на основе токенов JWT - пользователь отправляет имя пользователя и пароль в / account / auth, и выдается новый токен JWT. Затем JWT необходимо хранить в localalstorage или cook ie. Использование localalstorage означает, что JWT XSS уязвим и если маркер украден, злоумышленник может полностью выдать себя за пользователя. При использовании файлов cookie у нас по-прежнему будет проблема CSRF , которую необходимо решить. Мы рассмотрели метод double submit cook ie, но функция CSRF будет повторно ссылаться только на sh каждый раз, когда JWT будет переиздан, что создает окно для атакующего, чтобы узнать, что такое CSRF. Непонятно, какой метод лучше использовать.
Аутентификация на основе сеанса + аутентификация токена JWT - пользователь отправляет имя пользователя и пароль в / account / auth, создается сеанс, HTTP в браузере устанавливается только cook ie, а токен JWT отправляется обратно пользователю. PWA может аутентифицировать запросы с помощью JWT, и всякий раз, когда срок действия JWT истекает, приложение снова вызывает / account / auth для получения нового. Конечная точка / account / auth все равно должна быть защищена CSRF, однако ее влияние на удобство использования будет минимальным.
Похоже, что существует большое количество статей, утверждающих, что localStorage небезопасно и не должно использоваться, так почему такие крупные организации, как Amazon, все еще рекомендуют его? https://github.com/aws/amazon-cognito-auth-js - этот SDK использует localStorage для хранения токена.