Связывание токенов OpenID - PullRequest
Новая
       19

Связывание токенов OpenID

2 голосов
/ 22 января 2020

Я работаю в среде микросервисов, где каждая служба аутентифицируется с помощью OpenID Connect в сервис аутентификации (локальный IdP), основываясь на пользователях, которых я храню локально в своей базе данных.

Теперь мне нужны эти сервисы чтобы иметь возможность аутентификации с использованием Azure, Google, et c.

Могу (и должен) изменить мою службу аутентификации, чтобы разрешить перенаправление на другой IdP, и заменить или связать токен на мой фирменный токен для моих услуг? Есть ли более простой способ?

Как разрешить пользователям входить в систему с использованием имени / пароля ИЛИ внешнего IdP?

Ответы [ 3 ]

1 голос
/ 26 января 2020

Я также провожу некоторые исследования топи c, и из того, что я нашел до сих пор, кажется, что есть urn: ietf: params: oauth: grant-type: token-exchange тип предоставления, который должен позволять обменивать внешний idp-токен на внутренний, как описано в some spe c.

Он должен поддерживаться как часть конечной точки openid connect / token до тех пор, пока так как локальный idp поддерживает это, я думаю, что это должно быть наилучшей практикой для достижения того, что вы ищете.

В настоящее время я рассматриваю реализацию mitreid-connect idp как локальный idp. и некоторые из моих требований - также разрешить единый вход с третьими сторонами при возможности выдавать локальный токен из идентификатора внешнего пользователя.

Будет обновляться по ходу дела ...

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

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

Наш сервер аутентификации представляет собой узел express сервер со следующими свойствами:

  • Hosts stati c экраны входа в систему, чтобы разрешить аутентификацию против локальная база данных по электронной почте + пароль, а также предоставляет ссылки для аутентификации с внешними поставщиками OAuth2.
  • Как локальные, так и внешние запросы на аутентификацию перенаправляются на Паспорт. js Стратегии аутентификации
  • После успешного входа в систему как локальный, так и внешний паспорт. Стратегии js отвечают на обратный вызов. После этого ответа объект сеанса создается с помощью express -сессии и отправляется повар ie.
  • На этом этапе файлы cookie могут использоваться для обмена JWT, так что Аутентификация по API без сохранения состояния может быть возможна с токенами Bearer Access.
0 голосов
/ 25 января 2020

Если вы управляете всеми SP (вашими микросервисами), то определенно проще реализовать их на вашем общем IDP.

Но если SP являются внешними (как существующие сервисы, которые вы только что установили), и они уже реализуют publi c IDP, который вы хотите использовать, было бы немного сложнее пройти через ваш текущий IDP без проблем.

Я предполагаю, что вы в первом случае (вы сделали все свои SP ) поэтому я уточню это:

Когда ваш текущий IDP аутентифицирует пользователя в других опубликованных c IDP, он получит некоторую информацию (электронная почта, имя и т. д. c.), и вы сможете нормализовать их в Ваш ответ, чтобы быть уверенным в том, что ваш ИП полностью зависит от того, какой оригинальный IDP был использован c. Для вас будет лучше, если в будущем будет отлажена эта настройка. И, конечно, чтобы добавить новый publi c IDP ...

Но если вам нужно использовать какой-то конкретный c вызов оригинального IDP, (скажем, скажем, на Youtube API), вы можете иметь агности c API на вашем общем IDP, который перенаправит на соответствующий проприетарный API оригинального IDP, или отклонит запрос, если у IDP нет видеосистемы.

Или вы можете передать оригинальный SP своему SP, в пользовательском поле или области действия вашего токена oid c, например, SP, выделенный для видео, может напрямую вызывать API YouTube с токеном пользователя Google.

...