Сценарий обновления токена для поддержки входов с нескольких устройств с использованием express и passport.js - PullRequest
Новая
       20

Сценарий обновления токена для поддержки входов с нескольких устройств с использованием express и passport.js

0 голосов
/ 05 июля 2019

В настоящее время я работаю фронт-энд / мобильным разработчиком. Я вообще работаю над реакцией и реакцией нативных проектов. В большинстве случаев я пытаюсь создать аутентификацию для простых приложений. Я намерен создать базовый API Rest или GraphQL с пользовательскими логинами и т. Д. Я знаю, что есть такие опции, как Firebase, Auth0, Okta и т. Д., Но я хочу иметь возможность разрабатывать приложение, которое имеет собственную систему аутентификации. И мне нужна страница входа в мое приложение, например, 9gag, Twitter и т. Д. Это гигантские проекты с гигантскими командами, но вы поняли.

Я создал express.js API, который имеет имя пользователя / пароль для входа и поток токенов доступа jwt с passport-local и passport-jwt. Жетоны доступа имеют время жизни 30 минут. После этого пользователь отправляет токен обновления и получает новую пару токен доступа / токен обновления. Если я объясню это шаг за шагом;

  1. Пользователь входит в систему с именем пользователя и паролем. Токен доступа и токен обновления создаются и возвращаются клиенту. Кроме того, возвращается файл cookie с именем deviceId, который имеет случайное значение (возможно, я назову это значение sessionId, поскольку оно создается при каждом различном входе в систему). Я храню токены обновления в базе данных с userId и deviceId. Это «белый список» для обновления токенов.
  2. Пользователь вызывает API с токеном доступа.
  3. Когда срок действия маркера доступа истекает (или он истекает), пользователь передает токен обновления конечной точке /token.
  4. Эта конечная точка проверяет токен. Получает userId от него. Мы также получаем deviceId из куки. Мы проверяем базу данных и видим, существует ли токен обновления для этих userId и deviceId.
  5. Если все в порядке, конечная точка возвращает новую пару токенов доступа / обновления и обновляет токен обновления в базе данных.

Таким образом, если токен обновления захвачен и используется на другом устройстве, мы обнаружим, что deviceId нет в файлах cookie, и отклоним запрос. Черный список токена в базе данных (просто удалите его из белого списка).

Я получил эту идею deviceId cookie от GitHub. Это устанавливает cookie, как это при входе в систему. Когда я удалил его и попытался обновить страницу, мне прислали электронное письмо, в котором говорилось, что кто-то может попытаться украсть мою учетную запись, и защитный код для проверки моего сеанса.

Конечно, у него могут быть недостатки, но разве этот поток плохая идея? В большинстве уроков даже не говорится об обновлении токенов, а те, которые рекомендуют хранить токены обновления в базе данных, не решают ситуацию, когда пользователь может войти в систему на нескольких устройствах и оставаться в ней на каждом из них. Поэтому я добавил deviceId cookie к этому сценарию.

Дополнительно: Другая идея заключается в том, чтобы задействовать deviceId для запроса самого токена и удаления cookie из потока.

Я хочу использовать этот API для SPA и мобильных приложений. Другой вопрос - хранить токен обновления в SPA. Некоторые люди рекомендуют неявный поток (но я не хочу, чтобы пользователи перенаправляли на другой сайт для входа в систему). Некоторые говорят, что это хорошо хранить.

Любая рекомендация приветствуется. Спасибо!

...