Кто-Нибудь делал JWT token вместе с API Gateway? Чтобы сервер

авторизации был отдельным микросервисом и при авторизации заходили бы на него и получали токен, который мог бы использоваться при запросах на другие сервисы. Хотелось бы узнать какие инструменты оптимально использовать для этой задачи

кейклок ставишь и используешь

Зависит от проекта, если у тебя standalone-приложение, то, кмк, самое правильное - сделать свой authn-сервер, который будет ходить в разные IdP. Если же SaaS, то можно сразу использовать тот же кейклок для authn-сервера.

свой имплементировать?)

Да как хочешь, можешь взять готовый rp-клиент, я вот для своих проектов написал маленькую либу на го, так как остальные мне не понравились, но априори завязываться на кейклок не самая лучшая идея, OIDC все-таки про identity.

Собственно, spring-security позволяет делать и так(oauth2login), и так(resource server). Не говоря про spring authorization server.

Чего на него завязываться то, если работать как с oauth2 провайдером

Ты завязываешь на не свой authorization-сервер. Идея OAuth2 именно в том, что авторизационный сервер это third party, например существующий у клиента. Они дали client ID и client secret, и поставили время жизни ID Token'а в 60 секунд, и все, наша сессия теперь 60 секунд(особенно у кейклока проблемы с лайфтаймом). Поэтому нам необходим свой authn-cервер, который будет выпускать свои токены.

А зачем свой велосипедить? И какая проблема с временем жизни? Это все настраивается в пару кликов

Какой свой велосипед? Я не призываю писать свой rp-клиент, можешь взять существующий, я говорю о том, что OIDC не подразумевает использовать токены для авторизации, использование конкретного 3rd party сервера авторизации привязывает тебя к этому серверу авторизаций. И довольно распространенная схема использовать свой сервер авторизации со своими токенами(сессиями). Проблема кейклока в том, что время токена = время сессии в рилме, а не клиенте, уже несколько релизов это проблема, хотя это просто пример, возьми когнито, который часть полей не возвращает в idToken.

так, хорошо, что ты имеешь ввиду под своим сервером?

с токенами так и не понял прблемы

В стандартной терминологии OIDC, authn-server, issuer-токенов.

У тебя в стандартном флоу пользователь вводит креды в ui кейклока, получает токен, время жизни и содержимое токена определяет сам кейклок, его время жизни будет равняться жизни сессии, а сессия определяется на уровне рилма.

я имею ввиду фактически это что? своя разработка, что-то стороннее?

Фактически это твой сервер, конечно, как ты его будешь делать - только богу известно. Я написал свой rp-клиент для го, потому что остальное мне не понравилось.

Проблема в том, что оно должно работать на уровне клиентов, а не рилмов.

почему это не может быть кк?

в клиенте это тоже перегружается

Оно не работает.

отлично работает. у нас разные клиенты с разными настройками

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

у него стандартный интерфейс. берем и меняем на другой

Кого меняем? О чем ты? Ты не можешь просто так взять и поменять целый authn-сервер.

условно можно. url стандартные емнип