JWT / архитектура без сохранения состояния и большие данные безопасности

Question

Я немного запутался с понятием "без статов". У меня есть ситуация, когда мое приложение основано на архитектуре без сохранения состояния. Аутентификация выполняется с помощью токенов JWT (провайдеры аутентификации, такие как KeyCloack и OpenAM, не используются).

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

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

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

Большинство серверов имеют ограничение размера заголовка 8K, и, насколько я знаю, рекомендуется помещать токен JWT в заголовок.

Мой вопрос: как заставить эту работу работать без компромиссов: - Архитектура без сохранения состояния: сервер не должен хранить какую-либо информацию о сеансе. - Идентичность: чтобы выполнить запрос, сервер должен знать, к каким ролям и области данных пользователь может получить доступ - Ограничение заголовка: 8 КБ (я могу увеличить, но я не думаю, что это хорошая идея).

Спасибо за вашу помощь.

Answer 1

Извините, если я неправильно понял ваш фактический вопрос, но вы можете создать перехватчик, который будет прикреплять токен к заголовкам, если он присутствует в localStorage. И если вы хотите ограничить возможности пользователей по ролям, вам просто нужно хранить какой-то объект currentUser в одноэлементном (сервисе), где у вас будут все данные, например роли и т. Д. Таким образом, вы можете получить эти данные. в компонентах, и проверьте, разрешено ли currentUser вносить изменения или нет. В этом случае вы можете ограничить действие пользователя, чтобы не разрешать делать запросы, которые разрешены только для авторизованных / предоставленных пользователей. Кроме того, если есть некоторые маршруты, которые не должны быть доступны всем пользователям, но только для администратора (например), тогда вы можете сделать охрану маршрута и использовать его на маршруте в canActivate. Хотелось бы услышать немного больше подробностей, на случай, если я действительно неправильно понял ваш вопрос. И да, все это имеет смысл, только если это security data предоставлено в токене jwt, или вы можете запросить его и сохранить в своем объекте currentUser, который будет очищен при событии logout(), или когда сервер ответит 401 , 403 ошибки. Надеюсь, что хотя бы некоторые из пунктов здесь будут полезны.