Локальное хранилище с RESTful API для аутентификации пользователя.Это безопасный метод? - PullRequest
0 голосов
/ 21 октября 2018

Мне бы очень хотелось, чтобы некоторые мнения о том, является ли следующее безопасным методом в качестве аутентификации пользователя, и если нет, укажите его недостатки.

  • React front end
  • * RESTful API на основе 1007 * / MySQL на удаленном сервере

1) пользователь регистрируется, данные публикуются в API, пользователю по электронной почте предоставляется ссылка для одноразового использования, чтобы убедиться, что электронная почта действительна доони могут получить доступ к своей учетной записи.

2) пользователь входит в систему, API проверяет данные всеми обычными способами, а затем отправляет обратно объект JSON, содержащий их идентификатор пользователя и токен доступа.

3) Идентификатор пользователя и токен доступа устанавливаются в localStorage на устройстве пользователя при получении данных.Затем React получает эти данные из localStorage и использует их для установки и управления состоянием в хранилищах Redux , предоставляющих состояние Auth для всего приложения.

4) идентификатор пользователя и маркер доступа отправляются вместес каждым будущим запросом к API.В тех случаях, когда пользователь не вошел в систему, т. Е. Он не предоставляет действительный идентификатор пользователя с соответствующим токеном, ему автоматически запрещается запрашивать все, что требует аутентификации, в самой первой точке входа API.Подходящие ответы отправляются обратно, что, в свою очередь, обновляет состояние внешнего интерфейса, чтобы отразить незарегистрированного пользователя.

5) Когда пользователь выходит из системы, токен доступа удаляется из localStorage.

* 1026.* Немного подробнее о некоторых внутренних принципах работы:
  • Все токены генерируются на стороне сервера и хранятся в БД, они являются случайными и уникальными bin2hex(random_bytes(32)) и действительны только в том случае, если поставляются вместе ссоответствующий идентификатор пользователя.Таким образом, изменение идентификатора пользователя в запросе приведет к неудачному ответу на запрос аутентификации, равно как и предоставление действительного идентификатора пользователя с несоответствующим токеном или токеном с истекшим сроком действия.

  • Токены предназначены для одноразового использования и нового токенагенерируется, сохраняется и затем отправляется обратно в ответе от каждого аутентифицированного запроса вместе с соответствующим идентификатором пользователя.Это может быть излишним и создать дополнительную нагрузку на сервер.Очень бы хотелось, чтобы ваше мнение по этому аспекту было особенно впечатляющим.

  • Токены имеют срок действия 2 часа независимо.Поэтому, если пользователь оставляет себя в системе, он будет автоматически отключен через 2 часа бездействия.

  • Идентификатор пользователя и токен отправляются как часть JSON тела каждого запроса (не в заголовках).Является ли это причиной для беспокойства?

  • Ни при каких обстоятельствах (кроме регистрации и входа в систему) пароль пользователя не передается или хранится в localStorage или используется внешним интерфейсом React.Соответствующий идентификатор пользователя и токен - это все, что требуется для проверки пользователя после первоначальной авторизации.

  • Все соединения выполняются через HTTPS.

Можете ли вы обнаружить какие-либо явные угрозы безопасности в этом подходе?Я скучаю по слону в комнате здесь?

Очевидно, что идентификатор пользователя и соответствующий токен так же хороши, как и предоставление электронной почты и пароля пользователя при каждом запросе, поскольку аутентификация идет, но я не могу использовать сеансы PHPили куки *, поскольку API размещен в другом домене.Это лучший обходной путь, который я мог найти без необходимости идти по маршруту JWT или Oauth .

Насколько ошибочным может быть то, что я проверяю и проверяю данные API, здесь практически невозможно рассмотреть, но если предположить, что все это делается правильно, достаточно ли этот метод в принципе безопасен?

Я с нетерпением жду и заранее благодарю вас за ваше мнение :)

* без тонны обходных путей, которые в конечном итоге были бы излишними, поскольку это приложение можно использовать только с современными браузерами, которые все поддерживаютlocalStorage.

1 Ответ

0 голосов
/ 21 октября 2018

По моему мнению, не сохранять для хранения токена в локальном хранилище,

Как сказано в https://auth0.com/docs/security/store-tokens

, поскольку локальное хранилище браузера (или хранилище сеансов) не является безопасным.Любые хранящиеся там данные могут быть уязвимы для межсайтовых скриптов.Если злоумышленник украл токен, он может получить доступ к вашему API и запросить его.Обращайтесь с токенами как с номерами кредитных карт или паролями: не храните их в локальном хранилище.

Лучшим вариантом является использование файлов cookie, поскольку они управляются браузером.

...