При логине на сервере выдается пара токенов которые летят в редис
Как сделать так что бы при переходе на защищённый эндпоинт токен подставлялся в заголовки из редиса
p.s. В редисе значения хранятся по типу ключ: user_id, значение: токен
Непонятно на чем у вас бекенд пишется. Но в C# и .NET, это может быть примерно так,
Первая схема:
1. При попытке авторизации Пользователя, Клиентское приложение обращается к специальному Identity API, для авторизации;
2. В Identity API, проверяется, что пользователь зарегистрирован и имеет некие права(роль).
3. Происходит генерация открытого ключа, на основании секретного (скрытого ключа).
4. Этот самый открытый ключ, вместе с другой инфой, передается в Токене JWT Клиенту,
5. Клиент, при обращении защищенным ресурсам API, в запросе передает Токен в этот endpoint.
6. В этом endpoint, также должна быть возможность проверки поступившего Токена, на валидность, где основным моментом защиты, будет возможность в endpoint также на основании секретного ключа, определить действителен ли открытый ключ из поступившего Токена.
7. Если открытый ключ валиден API обрабатывает запрос.
Вторая схема:
Вся проверка выделена в отдельный третий компонент. В .NET это Duende Identity Server.
1. Различные клиенты обращаются в Identity сервео, за получением Токенов, на доступ к конкретным защищенным ресурсам,
2. Только после получения из Сервера Идентификации Токена, они передают его с запросом в API.
3. API получив Токен из запроса передает его на сервер Идентификации.
4. API получает от сервера идентификации подтверждение о валидности токена.
5. Получив подтверждение, что Токен в поступившем запросе был валиден, API предоставляет свои ресурсы.
Это примерная схема, и там еще куча деталей. Duende Identity Server может работать независимо от всех остальных частей приложения, Клиенты могут быть под Десктоп, под Веб, под мобилки. Защищенные API, также могут быть написаны на любом фреймворке. В этом видео коротко о Клиентах, Ресурсах и Токенах в Duende Identity Server.
Andrei SunnyPh, В JWT не передаётся никаких ключей. Информация из первых двух частей частей токена (header и payload) на сервере подписывается закрытым ключом. Алгоритмы хэширования и шифрования для подписи указаны в header. Затем подпись присоединяется к двум другим частям, формируя полный токен.
Проверка подписи также осуществляется на сервере. Из header читаются алгоритмы, по ним вычисляется хэш от двух первых частей токена и расшифровывается подпись. Вычисленный хэш должен совпасть с расшифрованным.
Оба ключа, закрытый и открытый хранятся на серверах, закрытый на сервере, выдающем токен, открытый на серверах, проверяющих токен. Естественно, это может быть один и тот же сервер. https://jwt.io/
Простой
