Добрый вечер, пытаюсь реализовать веб службу рест которая должна обеспечивать работу кино афиши.
Задачи рест сервиса отдать все фильмы, удалить, изменить описание фильма.
Секюрити - должно быть две роли админ и юзер, удалять и изменять описание может только админ. Аунтефикацию сделать с помощью jwt.
Находил статьи по этому поводу спринг секюрити + рест + jwt но на данный момент я только начал изучать сприн...
Как пытаюсь сделать я, WildFly сервер, + mongoDB + REST на jersey + сервлеты, и не могу понять как мне прикрутить jwt, , а именно понять логику работы во время аунтификации и после нее!!
С рестом кое как разобрался, а вот с секюрити нет, Вопрос какой принцип работы между клиентом и веб сервером при аунтификации jwt?
Например пользователь ввел логин и пароль нажал на форму войти, это полетело на указанный урл там сервак пользователю токен и где он хранится в браузере???? в куках или где?
Какой вообще принцип работы пользователя и сервера при аунтификации и какой уже после аунтификации?
Совет, объяснение, пример приветсвуется.Спасибо.
jwt в первую очередь используется в микросервисных архитектурах, когда конечный клиентский запрос будет обрабатываться одним из нескольких серверов.
Классически в такой архитектуре использовали механизмы OAuth. которые при обслуживании каждого запроса клиента осуществляли запрос на сервер OAuth - "клиент с токеном ААА запрашивает выполнение действия БББ"
Понятно что узким местом становится сервер OAuth - который должен выдержать "шторм" запросов при нагрузке. Вторым узким местом такой архитектуры становится увеличение времени ожидания ответа на запрос - внутри запроса как минимум будет выполнен 1 запрос авторизации.
Если мы говорим о "классическом" монолите, то на пример использование старых cookie требует от сервера держать в памяти все открытые сессии пользователей - тоже большая нагрузка на сервис авторизации.
JWT решает эти проблемы следующим путем: access токен сразу же содержит необходимую информацию: на пример о Ролях текущего пользователя, или о доступных ему действиях, кроме того предоставляет информацию о времени жизни этого токена. Обязательно в конце токена цифровая подпись. По ней собственно и проверяется "действительность" токена.
Алгоритм прост:
1. осуществить авторизацию - получить ответ 2 токена access, refresh.
2. обращаемся к микросервисам с использованием access токена.
3. если необходимо с помощью refresh токена обновляем access токен.
4. когда и refresh токен истек - осуществляем повторную авторизацию.
Где хранить JWT токен - где угодно. все зависит от инструментов и реализации. На пример можно реализовать хранение токена в LocalStorage, и пробрасывание его во время каждого запроса в виде header'а. Если один и тот же домен - то токен можно хранить в cookie и т.д.
Что хранить в виде полезной нагрузки? Сам разработчик должен для себя решить какой объем информации публиковать в таком токене, кроме того стоит учитывать что информацию из токена можно прочитать - это просто base64 кодированная JSON строка...
Простой