OpenID перенаправление против носителя - PullRequest
Новая
       90

OpenID перенаправление против носителя

1 голос
/ 11 февраля 2020

Я занимаюсь разработкой микросервиса на C ++ (по причинам низкой задержки) и начинаю погружаться в OpenID и Keycloak. Разработка на C ++ означает, что у меня почти нет поддержки библиотек для OpenID, но у меня (надеюсь) работают все детали низкого уровня (например, правильная проверка JWT). Я должен сделать все потоки связи и перенаправить себя.

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

В моем приложении три стороны:

  • Веб-клиент W
  • Микросервис A
  • Микросервис B

Общая связь между этими тремя: веб-клиент W может быть либо интерфейсом внешнего интерфейса, либо мобильным устройством, использующим только API в качестве службы без какого-либо интерфейса. W подключается к микросервису A, чтобы манипулировать данными и использовать их. Микросервис А обменивается данными с микросервисом В и наоборот. W не нужно знать о B.

До сих пор я думал о следующей архитектуре:

  • Для Web-клиента на Microservice Связь, которую я использовал бы для выделенных пользователей и клиентов с тип доступа «Publi c» в Keycloak, чтобы разрешить входы пользователя / pw
  • Для связи между микросервисом A и микросервисом B я бы использовал носитель типа доступа, потому что они никогда не инициируют вход в систему

Пожалуйста, сообщите, если вы считаете, что это звучит неправильно. Однако мой реальный вопрос заключается в том, какой тип потока регистрации требуется и какой шаг между ними я могу пропустить:

  1. Можно ли иметь конечную точку для входа в систему? микросервис A https://servicea.local/login, который перенаправляет запросы веб-клиента на OpenID / Keycloak. Например, веб-клиент отправляет имя пользователя, пароль, идентификатор клиента и тип предоставления на конечную точку запроса токена OpenID http://127.0.0.1: 8080 / auth / realms / somerealm / протокол / openid-connect / token ?

  2. Должен ли клиент взять токен и добавить его ко всем последующим вызовам в качестве токена авторизации?

  3. Должен ли микросервис реализовать обратный вызов для получения информации об авторизации?

  4. Следует ли вместо этого изменить поток, чтобы клиент мог обслуживать связь код доступа к сервису, которым он обменивается с токеном доступа?

Ответы [ 2 ]

0 голосов
/ 12 февраля 2020

Аутентификация (делегирование в Keycloak), а затем получение токена должны выполняться вашим пользовательским интерфейсом путем прямого контакта с keycloak, и этот токен должен передаваться из UI to A to B

Вот конечные точки OID C, которые блокируют ключ обеспечивает

https://www.keycloak.org/docs/latest/server_admin/index.html#keycloak -server-oid c -uri-конечные точки

0 голосов
/ 11 февраля 2020

Я бы стремился создать архитектуру, в которой роль ваших C ++ API-интерфейсов состоит в проверке токенов и обслуживании данных.

Однако клиентская часть - это отдельное решение, для которого требуется собственный код для входа в систему + работа с коды авторизации и получение токенов. Это не должно касаться вашего API - поэтому, чтобы ответить на ваши вопросы:

  1. Не рекомендуется
  2. Да
  3. Нет
  4. Нет

В эти дни все входы в систему должны происходить через системный браузер, независимо от того, пишете ли вы какой-либо из них. Этот код на стороне клиента, вероятно, не является C ++ и часто требует больше работы для создания API:

  • Веб-интерфейс
  • Мобильный интерфейс
  • Консоль / Настольное приложение

Если это поможет, у моего блога есть много рецензий и примеров кода об этих потоках. В следующем посте обратите внимание, что API не вызывается до шага 13, после того как веб-клиент завершит всю обработку входа в систему.

Рабочий процесс сообщения OAuth

...