Ещё наводящий вопрос - на основе чего каждый сервис при

кроссавторизации решает, что может доверять входным данным?

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

Проверили, что дальше? Что клиент передаёт в сервисы после авторизации? Проверили - где? На одном из сервисов? Может это сервис авторизации? Что он отдал клиенту и с чем клиент ходит в другие сервисы? Почему другие сервисы должны верить, что клиент действительно авторизован?

с чем пришел то и передает. названия городов если билеты найти хочет, например? не понимаю вопроса.

Клиент: Сервис А, авторизуй меня, вот мой логин и пароль. Сервис А: всё ок, можешь идти в сервис два за билетами. Клиент: Сервис 2, дай билетов. Сервис 2: А ты кто вообще? По каким входным данным запроса Сервис 2 знает, что это какой-то конкретный юзер и что он действительно авторизован?

По jwt токену который подписан ключем сервиса авторизации

Да, погоди, мы тут отрицаем JWT

Так а если мы тут вдруг взяли и инвалидировали на сервере всю сессию, а токен у клиента уже подписан. Как сервис 2 узнает, что надо такого клиента слать нахер?)

всегда можно спросить валиден ли еще токен и сервиса 1 :)

Ну так и возвращаемся к вопросу: нахера тогда вообще токены? Если на каждый запрос придется спрашивать где-то, валиден ли он. Вся суть токенов в том, чтобы как раз избавиться от таких вопросов в ущерб надёжности (в ущерб возможности резко оборвать сессию)

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

по коллбеку

А что он получит в этом коллбеке?

что сессия юзера всё, инвалидировать на своей стороне

для этого, как минимум, сервера должны быть под одним доменом и иметь общие ключи

https://t.me/modernperl/194509

Это если идентификатор клиента сувать в куку. А можно и не в куку

нет, не должны. куку не обязательно в куке передавать

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

тогда возвращаемся на шаг назад - клиент сходил за авторизацией - что он там получил?

redirect

Вопрос в другом и ответ на него очевиден. Хочешь надёжности и избавиться от общей базы: не получится.

Если под общей базой подразумевается сервис авторизации со своей базой, то да.

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

А, то есть мы пришли к тому, что для того, чтобы иметь сквозную авторизацию, нужно что-то, что будет её обеспечивать. Звучит логично. Никаких возражений.