OpenID Connect / oAuth: как разрешить провайдеру OpenId доступ к данным пользователя на стороне проверяющей стороны (клиента) - PullRequest
Новая
       18

OpenID Connect / oAuth: как разрешить провайдеру OpenId доступ к данным пользователя на стороне проверяющей стороны (клиента)

0 голосов
/ 16 января 2019

Мы планируем интеграцию между двумя сервисами: A и B.

Сервис A будет поставщиком OpenID, сервис B использует его для входа пользователей и создания новых учетных записей.

Служба A также предоставляет доступ к своим ресурсам через REST API с использованием авторизации OAuth, служба B использует маркер доступа OAuth, полученный с помощью потока кода авторизации OpenID.

Однако в некоторых случаях A хочет получить данные из B. Между этими службами существует установленное соглашение о том, что A может получить доступ к любым данным из B в области действия пользователя, который был создан с помощью OpenID Connect.

Как я могу разработать авторизацию для сервиса B API? Что A может предоставить B в HTTP-запросе?

Я рассматриваю такие вещи, как классический API Key, но это не выглядит естественным в этом рабочем процессе.

1 Ответ

0 голосов
/ 17 января 2019

Не существует прямого решения для вашего упомянутого сценария с точки зрения протокола OAuth и OpenID Connect.

Но, как вы пояснили, у вас есть службы, защищенные токеном доступа OAuth 2.0 в service A. Кроме того, A выступает в качестве поставщика удостоверений (с поддержкой OpenID Connect). Если это так, я считаю, что вы контролируете процесс выдачи токенов и проверки.

Один из вариантов - включить службы из B, которые защищены от токенов доступа OAuth 2.0. Что похоже на то, что у вас уже есть в A. И чтобы использовать эти сервисы, у вас будет несколько реализаций сервис / клиент, привязанных к A. Что они будут делать, так это получить токены от самого A для связи с B. Это может следовать за предоставлением клиентских учетных данных из OAuth 2.0 , поскольку нет никакого участия конечного пользователя (сценарий включает взаимодействие между сервисами).

Это предлагаемое решение аналогично использованию ключа API, но с дополнительным преимуществом протокола OAuth 2.0. Это позволяет создавать токены доступа с ограниченным сроком службы и при необходимости обновлять их. Кроме того, если вы хотите, чтобы услуги B были использованы другим клиентом, то все будет просто.

...