Как сделать аутентификацию без учета состояния (без сеанса) и без cookie?

Боб использует веб-приложение для достижения чего-то. А:

Его браузер находится на диете, поэтому он не поддерживает cookie.
Веб-приложение является популярным, он имеет дело с большим количеством пользователей в данный момент - он должен хорошо масштабироваться. До тех пор, пока сохранение сессии будет налагать ограничение на количество одновременных подключений и, конечно же, принесет незначительное ограничение производительности, нам может понравиться иметь система без сеанса:)

Некоторые важные примечания:

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

Теперь, как мы аутентифицируем Боба (по каждому запросу)? Что было бы разумным способом реализовать такую вещь?

играя в теннис с полномочиями через скрытые поля HTML-формы... в шаре содержатся учетные данные (имя пользователя и пароль), а две ракеты - браузер и Интернет соответственно. Другими словами, мы можем передавать данные туда и обратно через поля формы, а не через файлы cookie. При каждом веб-запросе браузер отправляет учетные данные. Хотя, в случае одностраничного приложения, это может выглядеть как игра в сквош против резиновой стены, вместо того, чтобы играть в теннис, поскольку веб-форма, содержащая учетные данные, может быть сохранена на всю жизнь веб-страница (и сервер будет настроен так, чтобы не предоставлять учетные данные).
сохранение имени пользователя и пароля в контексте страницы - переменные JavaScript и т.д. Здесь требуется одиночная страница, IMHO.
шифрованная аутентификация на основе токенов. В этом случае действие входа в систему приведет к генерации зашифрованного маркера безопасности (имя пользователя + пароль + что-то еще). Этот токен будет возвращен клиенту, и предстоящие запросы будут сопровождаться токеном. Имеет ли это смысл? У нас уже есть HTTPS...
другие...
В последнем случае: не делайте этого, храните учетные данные в сеансе! Сессия хорошая. С или без файлов cookie.

Возникает ли в вашей голове какой-либо вопрос о безопасности в Интернете или безопасности, касающийся любой из ранее описанных идей? Например,

time-outing - мы можем сохранить временную метку вместе с учетными данными (отметка времени = время, когда Боб вошел в его учетные данные). Например. когда СЕЙЧАС - временная меткa > порог, мы можем отклонить запрос.
Защита межсайтового скриптинга - никоим образом не должна отличаться, не так ли?

Большое спасибо за то, что вы нашли это время:)

Ответ 1

А, мне нравятся эти вопросы - поддержание сеанса без сеанса.

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

Один популярный, хотя и не полностью механизм без гражданства (при условии, что у вас есть исполнение JavaScript) заключается в том, чтобы встроить cookie сеанса в JavaScript. Парень безопасности во мне кричит на это, но он действительно может работать: каждый запрос имеет заголовок X-Authentication-Token или что-то в этом роде, и вы сопоставляете это с базой данных, файловым хранилищем в памяти и т.д. На бэкэнд для проверки Пользователь. Этот токен может иметь тайм-аут того времени, которое вы указали, и если он истечет, пользователь должен снова войти в систему. Он достаточно масштабируемый - если вы храните его в базе данных, его один оператор SQL выполнен и с правильными индексами, он должен занимать очень мало времени, даже при одновременном использовании нескольких одновременных пользователей. Однако тестирование нагрузки здесь определенно поможет. Если я правильно прочитаю вопрос, это будет ваш зашифрованный механизм токена, хотя я бы настоятельно рекомендовал использовать криптографически случайный токен, например 32 символа, по сравнению с использованием комбинации имени пользователя + пароля + все остальное - таким образом, он остается непредсказуемым, но вы все равно можете связать его с идентификатором пользователя или какой-то такой вещи.

В зависимости от того, что вы в конечном итоге используете, убедитесь, что оно отправлено вам безопасно. HTTPS защищает вас по кабелю, но он не защищает вас, если вы пропустите токен сеанса через URL-адрес (или, что еще хуже, учетные данные через URL-адрес). Я бы рекомендовал использовать заголовок или, если это не осуществимо, отправлять токен через запрос POST каждый раз (это будет означать скрытое поле формы в пользовательском браузере.) Последний подход использования запроса POST должен использовать защиту CSRF, просто в случае, хотя я подозреваю, что использование самого токена может быть чем-то вроде защиты CSRF.

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

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

Ответ 2

О опции входа в систему - я думаю, что обычно вы хотите поддерживать сеансы также для гостей.

Итак, если вы хотите принудительно ввести логин, параметр зашифрованного токена может быть хорошим. Возможно, это будет хорошо и для гостевой сессии. В другом направлении, я хотел бы объединить между добавлением токена в URL и теннисный вариант.

Обратите внимание, что отправка учетных данных только в URL-адрес может быть опасной. Например, вы можете пропустить токен через заголовок реферера HTTP или даже кто-то, кто просто проверяет ваш трафик или наблюдает за вашим компьютером.

Другое дело, даже если вы можете использовать куки файлы, я бы рекомендовал вам добавить случайный токен или случайный верификатор, чтобы защитить себя от атак типа Cross Site Request Forgery (CSRF).