Аутентификация - правильный способ обработки сессии с токенами - PullRequest
0 голосов
/ 21 января 2019

У меня есть приложение ReactJS SPA, которое подключается к ASP.NET Core WebAPI. API также является сервером авторизации благодаря OpenIddict. Я использую PasswordFlow и RefreshTokenFlow для обработки аутентификации, что означает, что сервер возвращает AccessToken и, необязательно, RefreshToken. В данный момент я борюсь с обработкой Правильно запомни меня . Когда пользователь хочет запомнить, это не имеет большого значения - сервер возвращает AccessToken и RefreshToken, которые хранит клиент, равный LocalStorage, поэтому он может обновить AccessToken, когда он истекает или истекает используя RefreshToken, и это нормально - в Интернете много статей и других полезных ресурсов. Проблема возникает, когда пользователь не хочет, чтобы его запомнили. Как обрабатывать аутентификацию по этому сценарию? Я вижу два решения:

  • сервер только выдает AccessToken, который клиент хранит в SessionStorage. Если он истекает - клиент заставляет пользователя повторно ввести свои учетные данные, чтобы получить новый AccessToken. AccessTokens должно быть недолгим (согласно тому, что я узнал до сих пор, он может составлять от одного до нескольких часов, но чем больше часов он действителен, тем менее безопасным он является в ситуации, когда его крадут. Если это продолжается в течение часа и после этого времени пользователь все еще использует приложение, кажется немного странным заставить его / ее снова войти в систему.
  • сервер возвращает AccessToken и RefreshToken, а клиент сохраняет его в SessionStorage. Во время сеанса, если срок действия AccessToken истекает, клиент может получить новый, используя RefreshToken. Это рискованно, так как сервер никогда не узнает, что пользователь закрыл свой браузер и что его / ее RefreshToken следует отозвать. Предполагая, что RefreshTokens имеют более длительный срок службы, это кажется очень рискованным.

Буду благодарен за любые мысли, предложения и идеи по этой теме. Спасибо!

1 Ответ

0 голосов
/ 23 января 2019

Если вы новичок, это сложно понять, но большинство реализаций работают так:

  • SPA использует неявный поток Open Id Connect через стороннюю библиотеку
  • Пользователи перенаправляются из SPA на сторонний сервер авторизации для входа в систему
  • Процесс входа полностью вне вашего приложения
  • После входа в систему Сервер авторизации возвращает токен вашему SPA
  • SPA вызывает API с токеном доступа

Надеюсь, это поможет вам понять общую форму вещей.

Gary

PS. Если это поможет, у меня есть Пример кода и несколько Письменных указаний , которые могут оказаться полезными.

В следующих статьях описывается, как автоматическое обновление токенов работает для SPA, и, как указывает Джон выше, SPA не использует токены обновления.

...