Возможна ли аутентификация с помощью приложения и сеансов на стороне клиента?
Независимо от того, как я рассуждаю об этом, кажется, что нет безопасного способа реализации отрисованного на стороне клиента одностраничного приложения, которое использует / получает доступ к информации о сеансах для аутентификации либо через файлы cookie, без серьезного ущерба для безопасности. В основном я хотел создать приложение React, но мне кажется, что мне нужно будет создать его с SSR для относительно безопасной версии аутентификации.
Случай использования, о котором я особенно думаю, - это когда пользователь входит в систему или регистрируется, а затем получает файл cookie с идентификатором сеанса. Оттуда, в реализации на стороне сервера, я могу просто настроить условный рендеринг в зависимости от того, имеет ли сохраненный на сервере сеанс связанный идентификатор пользователя или нет, а затем извлечь информацию о пользователе оттуда и отобразить ее.
Однако я не могу придумать решение для рендеринга на стороне клиента, в котором пользователь может использовать только идентификатор сеанса в файле cookie, который нелегко подделать. Некоторые из небезопасных реализаций включают использование хранилища браузера (локальное / сеансовое). Спасибо.
Ответы 1
Я думаю, что основная проблема здесь в том, что вы смешиваете две части веб-страницы (по крайней мере, в соответствии с тем, чего достиг HTML) и обрабатываете их обе как конфиденциальную информацию.
Веб-страница состоит из двух основных частей: первая - это формат отображения, а вторая - данные. При рендеринге / одностраничных приложениях на стороне клиента предполагается, что сам формат нечувствителен, и нужно защищать только данные.
В этом случае вам следует рассматривать перенаправление на стороне клиента для входа в систему как функцию качества жизни. Конечные точки данных на вашем сервере по-прежнему будут защищены - это означает, что теоретически неаутентифицированный пользователь может испортить статический HTML-код, который он обслуживает, и извлечь макеты страниц и шаблоны - но это было бы бессмысленно без данных для их заполнения - а это защищенная часть.
На практике вашим конечным продуктом будет одностраничное приложение, которое отправляет запросы к различным конечным точкам API для получения данных и заполнения запрошенных шаблонов страниц. Вам даже не нужно будет заходить так далеко, чтобы хранить сложные состояния сеанса - простого флага, уведомляющего клиента, аутентифицирован он или нет, будет достаточно (это выходит за рамки того, что вы обычно используете для аутентификации на стороне сервера, например файлы cookie или токены)
Теперь предположим, что я злонамеренный пользователь, который не замышляет ничего хорошего - я мог бы "обмануть" - или на самом деле просто открыть инструменты разработчика браузера и установить для флага isAuthenticated значение true, что позволяет мне пропустить экран входа в систему - что бы я теперь делал ? Теоретически я мог бы перейти к my-service / super-secret без перенаправления локально обратно на страницу входа на стороне клиента - а затем, как только соответствующая страница попытается загрузить данные с сервера с несуществующими учетными данными, произойдет сбой - в лучшем случае отображается сообщение об ошибке, в худшем - с некоторым внутренним исключением и представлением, показывающим неработающий шаблон.
Итак, чтобы вкратце подчеркнуть:
A. Если вы хотите защитить свой ШАБЛОН, тогда нет никакого способа достичь этого на стороне клиента.
B. Если вы хотите защитить свой ДАННЫЕ, то вам следует рассматривать блокировку / предотвращение перехода пользователей на защищенные страницы как функцию качества жизни, а не как функцию безопасности, поскольку она будет реализована на сервере при обслуживании данных для этого. конкретная страница.
Я просто прочитал эту статью, потому что у меня был тот же вопрос, и это действительно помогло мне лучше понять проблему.
Вы изучали JWT? (jwt.io) Хранение токена в cookie или даже в локальном хранилище полностью безопасно.