Что выбрать для SSO и как лучше сделать общение сервисов?
Задача следующая: необходим какой-то сервер авторизации с UI, чтобы пользователи могли регистрироваться, менять свои данные и пр. и в дальнейшем к нему могли обращаться сервисы для получения каких-то данных о пользователях.
Так же сервер должен иметь API, чтобы другие сервисы могли запросить у него, например, список пользователей, чтобы можно было их выбрать в качестве исполнителя задачи (как пример).
Сервисы будут внутри компании, только в локальной сети (если это важно).
Вопрос 1: что лучше всего взять для авторизации/регистрации? Keycloak или написать какое-то свое решение?
Вопрос 2: как организовать общение сервисов, если я, условно говоря, нахожусь в сервисе создания задач, а мне нужно получить список исполнителей, то сервис задач должен сходить сам в сервис авторизации и получить список пользователей, но доступ без ключа к такому открывать будет странно, поэтому как быть в этой ситуации? Разрешать всем авторизированным пользователям получать эти данные и просто брать токен пользователя из запроса и пробрасывать его дальше? Так же сервис задач может обращаться еще к нескольким сервисам внутри организации.
Вопрос 3: Есть ли какие-то SSO системы без JWT, а на статичных токенах, которые не имеют срока действия и лежат, например, где-то в Redis'e? И чем такие токены будут хуже, чем JWT?
Так же, если важно, то стек такой: UI на Blazor WASM, сервисы на ASP.Net Core Web API.
А что мешает разделить SSO и Users сервис? SSO будет отвечать за логин (можно и регистрацию), выдачу/обновление токена. А через Users сервис будете регистрировать, удалять и менять данные пользователей.
Петр, Да никаких. Вопрос в целом про то, что делать с авторизацией, как передавать токен из сервиса в сервис, как быть с ролью доступа к списку пользователей и прочее.
OwDafuq, Так при обращении сервисам они будут перебрасывать на SSO, который после логина вернет обратно на страницу сервиса, ведь в первоначальном запросе прописывается return url. По возвращенному коду и получит сервис токен. И с этим JWT токеном можно конектится ко всем сервисам.
При переходе от сервиса к сервису можно передать в запросе перехода refresh токен, которыv можно обновить access token.
Роль доступа может храниться на сервисе авторизации, а SSO и User сервис внутри себя имеют прямой доступ к нему.
Как вариант и в SSO можно добавить эндпоинт, что будет при запросе с полученным JWT кокеном отдавать все роли и пермишены сделавшего запрос.
Петр, Сейчас сделано так: самописный сервис для выдачи JWT, в нем же регистрация, авторизация по refreshToken'y или паролю, изменение пользователя, управление ролями. Но мне не очень нравится JWT, на сколько будет адекватно сделать свою авторизацию на статичных токенах (которые не надо обновлять), хранить их в Redis, так же этот токен пересылать от сервиса к сервису в заголовке, а на сервисе будет своя схема авторизации, которая будет делать обычный get запрос к сервису авторизации с этим токеном, а он будет отдавать все claims'ы, которые есть у этого токена. Так же туда можно будет добавить и свой "client-id", чтобы понимать какому приложению какой токен относится. На сколько это будет выглядеть адекватно?
OwDafuq, Так JWT токен с малым временем жизни это для безопастности. Если она не нужна, то в настройках SSO просто поставьте, что access token живет 5 лет и всего делов.
Петр, Просто смотрю пример в яндекс апи, там точно так же выдается API ключ, который может жить хоть 1000 лет. Просто какие могут быть подводные камни при таком подходе, как я выше описал?
Средний
