Я пытался прочитать как можно больше разных ответов и сообщений, но я все еще не могу полностью решить решение, которое соответствует моим потребностям. Я пытаюсь разработать лучший (наиболее эффективный, но в большей степени более безопасный) способ обработки аутентификации пользователя, входа в систему и т.д.
У меня есть сервер Node.js, работающий в Express; У меня есть веб-приложение Angular.js; и у меня есть приложение для iOS. Я открываю API RESTful с помощью Express/Node.js.
Cookies
Первое, что я прочитал, - это использовать куки файлы и хранить токен/идентификатор сеанса на стороне сервера (хешированный) и на стороне клиента (unhashed). Клиент будет передавать этот идентификатор с каждым запросом, сервер будет хешировать его, анализировать и обрабатывать запрос соответствующим образом. Это не означает, что RESTful (не большая проблема), но что более важно, мне пришлось бы дублировать мой API: один для аутентификации имени пользователя и пароля (например, выполненный через curl) и один для проверки подлинности на основе файлов cookie (например, моего веб-приложения)?
Еще одна проблема с этим: что бы я сделал, если бы у меня было несколько соединений от одного пользователя, например. они вошли в два браузера, iPhone и iPad. Будет ли мое хранилище идентификаторов сеансов теперь быть массивом?
HTTP Basic Auth
Следующей идеей было использование HTTP Basic Auth (с SSL), которое кажется достаточно простым, но не рекомендуется, потому что вам необходимо передать имя пользователя и пароль с каждым запросом. Если бы я должен был сделать это с помощью HTTP Basic Auth, я бы сохранил имя пользователя и пароль в файлах cookie (или локальном хранилище HTML), чтобы использовать функцию "Запомнить меня"? Или я мог бы объединить два: использовать HTTP Basic Auth для фактических запросов (опубликовать новое сообщение и т.д.) И просто использовать идентификатор сеанса, хранящийся в файле cookie, для первоначального входа в систему/запомнить меня аспекты?
Является ли передача идентификатора сеанса более безопасным, чем просто передача пароля пользователя? Как? Идентификатор сеанса будет действовать якобы как пароль, поэтому для меня передача будет иметь те же проблемы безопасности, что и передача пароля.
Базовый Auth, по-видимому, поддерживается на всех платформах, что идеально. Кажется, что основным недостатком является передача данных аутентификации клиента с каждым запросом. Есть ли способ смягчить эту проблему?
OAuth
OAuth кажется излишним для моих нужд. Я думаю, что потерял бы способность выполнять команды curl для тестирования моего API. Как OAuth улучшает метод cookie?
Как вы, вероятно, можете сказать, меня немного смущает разнообразная информация, поэтому, если у вас есть набор хороших ссылок, применимых к этому сценарию, я бы с удовольствием их прочитал. Я пытаюсь найти решение, которое подходит для всех платформ, но по-прежнему максимально безопасно. Кроме того, если у меня есть какая-либо из моих терминов неправильно, пожалуйста, исправьте меня, потому что это облегчит мне поиск.
Спасибо.
Update:
Я думал об этой проблеме, и у меня была идея. Скажите, пожалуйста, если это глупо/небезопасно/любая обратная связь, потому что я не уверен, что это хорошо.
Когда пользователь входит в систему, мы генерируем случайный идентификатор сеанса (соленый и т.д.). Этот необязательный идентификатор сеанса отправляется клиенту, который клиент может хранить (например, в файлах cookie), если они выбирают; идентификатор сеанса хранится в базе данных.
Этот идентификатор сеанса затем по желанию отправляется с каждым запросом как заголовок HTTP-аутентификации или строка запроса, либо клиент может просто отправить имя пользователя и пароль, если они захотят (что дает нам наш обычный REST API). На конце сервера мы сначала проверяем параметр идентификатора сеанса, если он отсутствует, мы проверяем имя пользователя/пароль. Если не существует ошибки.
На сервере мы проверяем, что идентификатор сеанса связан с правильным именем пользователя. Если это так, мы завершаем запрос.
Каждый раз, когда пользователь входит в систему, мы создаем новый идентификатор сеанса или удаляем текущий и отправляем его с ответом на запрос журнала.
Я думаю, что это позволяет мне использовать обычный REST API, где это уместно, с Basic Auth и поддерживать сеансы/запоминать мне функциональность. Он не решает проблему множественных журналов, но в остальном я думаю, что этот путь должен был бы. Пожалуйста, дайте мне знать.