Зачем нужен Single Sing On - в общем то понятно, микросервисы тут не при чем.
Как настроить SSO и как с ним работать - наверное читать в доке по тому продукту поддерживающему SSO, который используете )))

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

IMHO

P.S.
Картинку не понял. Т.к. например в SSO от Oracle, аутентификация проходит на HTTP сервере. Т.е. сервер(служба) аутентификации работает МЕЖДУ клиентом и нашим приложением (микросервисом). Если клиент аутентификаци не прошел, до приложения (микросервиса) запрос даже доходить не должен.

redwhite90Ну то есть Вы полагаете, что надо сделать какой-то фасад, который на котором будет проходить аунтефикация.

Нет. Я полагаю, что все уже сделано до нас. Это задача SSO и Web Server'а (или Application Server'а если он берет на себя задачу обслуживания внешнего HTTP).

redwhite90Если аунтефикация пройдена, то всё доступно.

Не все. А в рамках полномочий данного пользователя.

Если ф-ции приложения разнесены по раным URL / страничкам / servlet'ам , то возможно даже задачу разграничения полномочий может взять на себя Web Server

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

redwhite90Сам этот фасад с другими микросервисами работает без авторизации? миросервисы друг с другом тоже?
Наверное зависит от задачи (и архитектуры) и от степени параноидальности людей отвечающих за секьюрити

Моя точка зрения, что они МОГУТ работать без авторизации. Точнее, сам факт наличия IP из внутренней подсети - может уже быть достаточным основаниям доверять источнику запроса.

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

Ну и остается определить, что такое "авторизация".

На мой взгляд, это процесс проверки user name + password и выдача user id (или некоего другого "токена"). Ее достаточно делать один раз.

НО в наиболее параноидальных случаях, возможно требуется делать на каждую операцию (пример: банкомат, попросили баланс - требуют пин-код, попросили снять деньги - опять требуют пин-код)

Petro123Arm79его наличие,где именно он должен лежать?

IMHO Он должен быть в REST запросе, который приходит на микросервис

Как я понимаю, после SSO токен в том или ином виде хранится в куках (или другом механизме связанном с сессий) клиента. Но опять таки, это лучше читать в доках конкретного SSO.

p.s. специально не углябляюсь в детали реализации, т.к. это зависит от используемого софта + я с этм детально не работал. В настройке SSO от Oracle (SSO, Weblogic, Oracle ADF, Oracle BI) участвовал.
К примеру подозреваю, что ни о каких JWT-токенах SSO от Oracle не знает )))

Arm79....к разным кускам логики должны быть авторизированы.
...
У вас иное мнение?
В исходном вопросе автора, смешаны "люди и кони"
1. Обращение ОТ ПОЛЬЗОВАТЕЛЕЙ к сервисам - да, должны, беспорно
2. Общение МЕЖДУ СИСТЕМНЫМИ сервисами - если общение в защищенной среде (внутренняя IP сеть сервеной), то не факт. Большенство обращений все равно должны быть в режиме Superuser (видеть все данные).

IMHO & AFAIK

redwhite90Вообще токены стараются не засветить. Они обычно на сервере лежат и в браузер не попадают. SSO токен это oauth2 токен?
Не готов говорить без ссылок на конкретную доку/технологию/софт/архитектуру/требования

странно, как его можно не светить.

Я вошел в одно приложение, аудентифицировался, мне выдали токен
Теперь я хочу войти в другое приложение, вообще НЕ связанное с первым. Аудентифицироваться не хочу, т.к. у нас SSO.

Явно, что для данного сценария, клиенту нужно знать свой токен. И никакие прокси тут не спасут, т.к. SSO оно не только для Web, но и для обычных приложений, м даже MS DOS приложений )))