"это не то о чём должна болеть голова" не согласуется с "при потере сервер-сайд сетевой связности", в первом случае почему-то предполагается именно компрометация, в то время как во втором это просто "потеря". Либо в обоих случаях "это не то, о чём должна болеть голова", либо крестик с первого стоит убрать
Кажется речь о разных процессах. Если «моргнул» IAM, то по уже выданым АТ все сервисы останутся доступными. А вот RT все считаем невалидными и если IAM лег на долго (больше ttl AT), то и правда всех вылогинит. А в классических сессиях все еще хуже, если авторизация упала то у тебя сразу все умрут (причем еще в непонятном состоянии на пол запроса), ведь у тебя на каждый клиенский поход в сервис с кукой есть сервир-сайд поход в авторизацию типо /checksession, это твоя точка правды где все проверяют валидность сессии.
Отдельно стоит упомянуть что в этой точке правды у тебя огромная нагрузка будет (с АТ схемой ты размазываешь нагрузку на каждый сервер т.к. они проверяют сессии сами)
Отдельно замечу, что часто тебе надо довозить профили пользователей на всех потребителей и у тебя все равно сервер сайд хитты будут, но их можно хотя бы кешировать. Тут ситуативно, если продукт предполагает что так и так будут походы в базу за данными, то может и авторизацию не смысла «оптимизировать»