OpenID Connect User Mapping

Question

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

Нас попросили внедрить SSO для этих веб-приложений, и в результате я читал об OpenID Connect. Я считаю, что это было бы лучшим решением, чем SAML, учитывая, что (a) конечные пользователи не всегда являются корпоративными пользователями, и (b) SAML не предназначен для мобильных приложений.

Полагаю, я достаточно хорошо понимаю течение, но у меня есть один недостаток. Чтобы позволить пользователям проходить аутентификацию с использованием внешнего IdP, нам необходимо сопоставить пользователя с нашим внутренним идентификатором. Например, пользователь проходит проверку подлинности с использованием OIDC / Google, в результате чего мы получаем уникальный идентификатор пользователя Google (и адрес электронной почты и т. Д., Если мы запрашиваем дальнейшие запросы), но это бесполезно для нас, пока мы не сможем сопоставить идентификатор Google с внутренним идентификатором клиента.

Это отображение выходит за рамки OIDC? Если это так, есть ли лучший метод для этого? Я уверен, что мы не одиноки в этом требовании ...

Спасибо, John

Answer 1

Это отображение выходит за рамки OIDC?

Краткий ответ, да! Если ваш бэкэнд требует сравнения / проверки с внутренними идентификационными данными, то это должно быть сделано за пределами протокола OpenID Connect (OIDC). OIDC просто определяет процесс получения токенов (ID и токена доступа), которые необходимы для аутентификации и авторизации.

есть ли метод наилучшей практики для этого?

Один из вариантов - использовать внешнюю синхронизацию каталогов. Например, поставщик Google Google Cloud Directory Sync (GCDS) , который позволяет синхронизировать идентификационные данные с LDAP или MS Active Directory. Другой альтернативой является использование протокола SCIM для динамической связи и предоставления пользователям. Например, Google также предоставляет такую ​​поддержку .

В качестве альтернативы, вы можете использовать своевременное предоставление во время получения токенов. Эта поддержка будет зависеть от реализации вашего поставщика удостоверений. Например, сервер идентификации WSO2 поддерживает как JIT , так и SCIM.