Безопасный способ обработки возвращаемого пользователя в ember?

Question

Я использую ember для создания веб-сайта ui для сайта, для которого требуется вход в систему. Предположим, браузер сохранил некоторые файлы cookie с последнего входа пользователя. Теперь пользователь снова посещает сайт. Итак, безопасный и распространенный способ для ember регистрировать пользователя автоматически на основе cookie с последнего посещения? Если да, то каковы общие способы его реализации? (Я ничего не могу найти от Google.) Кроме того, как мне создать файл cookie при входе в систему? Это распространенный способ просто поместить идентификатор пользователя, хэш пароля и истечение срока действия в cookie?

Кроме того, любые ссылки, связанные с этой темой, очень ценятся.

Edit 1
В свете ответа Вохуман, я думаю, что я могу сделать мой вопрос немного более конкретно. В принципе, то, что я хочу знать, - это обычная и безопасная реализация, позволяющая пользователю войти в систему, даже когда они закрывают и снова открывают браузер. А именно, время жизни выходит за рамки сеанса. Возьмите, например, ссылку. Если вы вошли в систему и покинули браузер. Затем в следующий раз, когда вы перейдете в ссылку, вы все равно авторизуетесь автоматически. Прямо сейчас, что я могу представить, это решение, подобное следующему.

При первом входе на сайт сервер вернет куки-файл, содержащий маркер хеш-аутентификации. Затем в следующий раз, когда вы перейдете на сайт, сервер получит хеш-маркер и, таким образом, проверит вашу сессию.

Значит, выше потока в основном то, что люди обычно делают, чтобы пользователь вошел в систему? Если это так, является ли JSON Web Token (JWT) главным образом одним из способов создания хеш-маркера, упомянутого выше? Кроме того, если предположить, что соединение является HTTPS, этот подход кажется мне безопасным. Это не?

Edit 2
This article дает интересную дискуссию о том, где хранить маркер доступа.

Answer 1

Это безопасный и распространенный способ, позволяющий ember регистрировать пользователя автоматически на основе файла cookie с последнего посещения?

Да и нет. Безопасность - сложная тема. Обычно файлы cookie сеанса используются для авторизации пользователей. Это на самом деле самый используемый метод хранения пользователей вошел в систему. Если пользователь не может защитить свои учетные данные, то любые уровни безопасности могут быть уязвимыми.

Для одностраничных приложений обычно используются токены доступа, а не файлы cookie и сеансы. Клиент отправляет учетные данные пользователя, а сервер возвращает токен доступа. Токен зашифрован и выдается заново и может быть сохранен в localStorage или sessionStorage. Использование JSON Web Tokens (JWT)standard - популярный способ реализации аутентификации пользователей и авторизации в веб-службах. Например, API Open Open API использует токены доступа.

JSON Web Токен (JWT) представляет собой компактный, URL-безопасные средства репрезентации претензии должны быть переданы между двумя сторонами. Претензии в JWT кодируются как объект JSON, который используется как полезная нагрузка структуры веб-подписи JSON или как открытый текст структуры JSON Web Шифрование (JWE), позволяющее получить формулу в цифрах подписанный или защищенный целостностью с кодом аутентификации сообщения (MAC) и/или зашифрованным.

редактировать:

Таким образом, выше потока в основном то, что люди обычно делают, чтобы пользователь вошел в?

Для традиционных сайтов да.

Весь смысл использования токенов доступа заключается в сохранении веб-сервиса/API stateless. Это означает, что серверу не нужно хранить файлы cookie/сеансы для аутентификации и авторизации пользователей. Безстоящий является одним из ключевых факторов внедрения веб-сервисов, которые следуют парадигме REST. Это клиент, который должен хранить токен и отправлять его на сервер (через заголовок авторизации или параметры запроса). Сервер не сохраняет токен. Конечно, вы можете хранить токены на сервере, если хотите добавить еще один уровень безопасности, но это не так часто и не обязательно. Хранение токенов на сервере также может сделать ваше приложение уязвимым для атак базы данных и не рекомендуется.

Если вы хотите сделать процесс более безопасным, вы можете уменьшить время действия токенов доступа (1 час, 1 день или 1 неделю, это зависит от вас).

Что касается localStorage, то это безопасно?

localStorage данные хранятся отдельно для каждого источника (домена). Злоумышленник может читать данные только в том случае, если у него есть доступ к пользовательскому браузеру. Вы должны убедиться, что у вашего приложения нет уязвимостей XSS, поэтому злоумышленники не могут вводить какие-либо скрипты в ваше приложение. На самом деле это другая тема.