Варианты хранения и обновления токенов sh в SPA - PullRequest
Новая
       5

Варианты хранения и обновления токенов sh в SPA

1 голос
/ 22 января 2020

Я читал проект Aaron Parecki, основанный на браузере приложений (то есть SPA, подобных тем, которые были разработаны с React или Angular), лучшие практики аутентификации с OAuth 2, а также рекомендации по безопасности OW ASP, и это оставило меня действительно запутался:

  1. В проекте RF C упоминаются вращающиеся токены refre sh. Теперь, как бы я это сделал, придерживаясь ограничения REST без сохранения состояния? Нужно ли включать какой-то дайджест случайной строки в поваренную строку ie и токен refre sh и проверять, равны ли они?
  2. Каков правильный путь (или, скорее, некоторые из более безопасные способы) хранения refre sh токенов в браузере? Я проверил JS auth библиотеку okta, и она по умолчанию использует localStorage, против чего рекомендуются рекомендации OW ASP. Есть ли какая-то дополнительная защита? Должен ли я добавить в него какой-то дополнительный дайджест, а также поместить его в cook ie и сопоставить их?
  3. OW ASP рекомендует, чтобы идентификаторы сеансов были полностью непрозрачными для клиента, но если мы используем JWT, не нарушает ли этот принцип? Означает ли это, что я всегда должен шифровать свои JWT с помощью симметричного c шифра?

Некоторые ссылки:

1 Ответ

1 голос
/ 22 января 2020

Стандартным вариантом для SPA является использование фреймов для автоматического обновления токенов и вообще не использовать refre sh токенов.

Моя запись на Хранение токенов пользовательского интерфейса также может представлять интерес - поскольку решение представляет собой компромисс между безопасностью и удобством использования.

Самый безопасный вариант - хранить токены в памяти браузера - но затем обновление страницы означает, что пользователь перенаправлен войти снова. Поэтому обычно используется HTML5 хранилище сеансов для краткосрочных токенов доступа.

My Cloud SPA использует AWS Cognito (потому что это дешево), который не поддерживает стандарты .

Вместо этого он выдает в SPA SPA токен refre sh. Мое решение использует промежуточный принцип хранения токена доступа в HTML5 хранилище сеанса и токена refre sh в памяти.

Доступны 2 варианта здесь :

  • Okta использует iframes
  • Cognito использует refre sh tokens

Возможно, это станет проще, и я думаю, что все согласны с тем, что нынешние руководящие указания на основе стандартов неоднозначны.

По состоянию на начало 2020 года решение iframe и хранилище на основе памяти или сеансов является наиболее стандартным - как в этой статье автора самой широко используемой библиотеки безопасности SPA.

...