Spring Gateway, который генерирует токен JWT

Я пытаюсь построить шлюз с весенним облаком. Он должен выполнять некоторую логику, если JWT существует и не существует, он должен создать его (с нуля). У меня есть пример из Интернета, и все они используют oauth2, и я этого не хочу. Кто-нибудь знает из примера, подобного тому, о чем я говорю. Я новичок в Spring-Cloud-Gateway и Spring-Security

Я пробовал https://spring.io/blog/2019/08/16/securing-services-with-spring-cloud-gateway, но я запутался со всей частью oauth.


jwt spring-security spring-cloud-gateway
person Elena    schedule 08.11.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Разделение проблем

Шлюз

Задача шлюза - маршрутизировать запросы. И делай это хорошо.

Spring Cloud Gateway предоставляет простой, но эффективный способ маршрутизации к API.

Служба аутентификации

Задача службы аутентификации - аутентифицировать пользователей, например быть единственной службой, имеющей доступ к метаданным пароля пользователя, и единственной службой с доступом к закрытым ключам, используемым для подписи токенов JWT.

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

person Jonas    schedule 08.11.2019
comment
У меня есть некоторые требования к пользователю. Мне понадобятся клиентские сертификаты для аутентификации. Для каждого правильно аутентифицированного я должен сгенерировать токен. Я понимаю, что когда у пользователя нет токена, он должен быть перенаправлен на токен сертификата клиента. Когда пользователь находится в системе, клиент хочет, чтобы его «сеанс» никогда не заканчивался, поэтому каждый раз, когда пользователь подключается к системе, нам нужно будет продлевать срок действия токена. Когда мы обновим программное обеспечение, нам нужно будет отменить его токен и воссоздать новый, чтобы он получил доступ к новой версии. - person Elena; 09.11.2019
comment
Наш клиент не хочет, чтобы мы снова запрашивали сертификат клиента при обновлении программного обеспечения. Итак, единственное решение, которое я вижу, - это то, что шлюз API имеет некоторый контроль над токеном, чтобы отозвать его и автоматически воссоздать. - person Elena; 09.11.2019
comment
@Elena, как я понимаю, клиентские сертификаты - это только способ аутентификации с помощью службы аутентификации, например вместо паролей. Итак, архитектура будет такой же, как я описываю. - person Jonas; 09.11.2019
comment
Меня беспокоит то, что если мне нужно изменить время истечения срока действия токена с каждым HTTP-запросом, мне нужно перенаправить на вызов службы аутентификации, чтобы этот компонент возвращал правильно подписанный JWT с новым сроком действия. - person Elena; 09.11.2019