#javascript #reactjs #jwt
#javascript #reactjs #jwt
Вопрос:
В настоящее время я изучаю аутентификацию и авторизацию, разрабатывая простое веб-приложение с использованием .NET Core и React. У меня настроен сервер с множеством защищенных маршрутов с использованием jwt. Прямо сейчас после входа в систему я получаю токен доступа, токен обновления и текущую роль пользователя и сохраняю их в файле cookie. Это работает нормально, однако, если бы пользователь изменил свою роль, скажем, на Admin, я бы столкнулся с некоторыми проблемами. У него по-прежнему нет доступа к конечным точкам администратора, поскольку сервер получает фактическую роль из токена доступа, но пользовательский интерфейс администратора отображается. Существует аналогичная проблема с самим токеном, в моей текущей реализации пользователь считается аутентифицированным, если cookie не является неопределенным, поэтому гостевой пользователь может вставить туда какую-то тарабарщину, а также увидеть некоторые компоненты навигации, которые он не должен видеть. Я вижу много примеров в Интернете, когда люди используют localStorage для хранения пользовательской информации, но я думаю, что это приведет к той же проблеме. Мой главный вопрос заключается в том, является ли это большой проблемой безопасности в первую очередь (поскольку пользователь видит только некоторые дополнительные кнопки, которые ничего не делают при нажатии), и если да, то каков хороший способ ее решения? Я думал о получении текущей роли пользователя с сервера (и одновременной проверке самого токена), но мне нужно было бы делать это каждый раз, когда я хочу отобразить навигационный компонент, поэтому это звучит довольно неуклюже.
Комментарии:
1. 1) localStorage — хороший способ. 2) Вы, вероятно, будете дублировать логику между частями клиента и сервера, чтобы обеспечить наилучший пользовательский интерфейс. 3) периодически перепроверяйте авторизацию текущего пользователя у клиента, вызывая сервер, обновляя localStorage и изменяя свой пользовательский интерфейс. 4) в идеале эти изменения происходят нечасто. 5) длительность кэша — это то, как долго вы можете разрешить пользователю переходить с admin на non-admin или с valid на revoked. 6) Рассмотрите возможность создания атрибута авторизации, который вы можете применить на уровне класса контроллера для обработки функций «администратора» и оплаты проверки при каждом вызове.
Ответ №1:
Токены в JWT предназначены для того, чтобы их никто не мог изменять (содержимое токена не будет соответствовать его подписи), если разрешения изменяются, например, путем получения прав администратора, серверной части необходимо обслуживать новый токен.
Что касается безопасности: вы всегда должны позволять серверной части проверять токен jwt и прогнозировать, разрешено ли пользователю выполнять определенное действие с помощью информации, предоставленной в токене (например, роль или разрешение).
Отображение страниц администратора или их скрытие — это исключительно пользовательский сервис, а не концепция безопасности. Таким образом, кто-то может изменить localStorage по своему усмотрению и, возможно, просматривать страницы администратора, но фактически не может выполнять какие-либо операции, связанные с администрированием, в серверных системах.