Мне бы очень хотелось, чтобы некоторые мнения о том, является ли следующее безопасным методом в качестве аутентификации пользователя, и если нет, укажите его недостатки.
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
.