OIDC: несколько органов используют одного и того же эмитента, обеспокоены?

У нас есть решение для подключения к многопользовательскому серверу идентификации с открытым идентификатором, в котором каждый арендатор/клиент в настоящее время имеет свой собственный URL-адрес авторизации и информацию о метаданных. Мы используем одни и те же ключи для подписи jwt для всех арендаторов. Пример URL-адреса полномочий для одного клиента: https://auth.ourdomain.com/tenant123. (причина историческая и ее не очень легко изменить)

Хотя нам нужны разные URL-адреса авторизации для каждого арендатора, мы действительно предпочли бы как можно больше простоты, когда дело доходит до проверки подписанных jwts при создании внутреннего API и для третьих сторон. В настоящее время uri эмитента также зависит от арендатора, но мы думаем об изменении этого, чтобы все арендаторы использовали один и тот же uri эмитента, и, таким образом, проверка jwt могла выполняться по фиксированному uri центра.

Помимо зависимости от того, что все органы должны использовать одни и те же подписывающие jwks, есть ли какие-либо опасения по поводу того, что несколько органов используют один и тот же uri эмитента, когда речь идет о безопасности, спецификации или просто рекомендуемой передовой практике?


person David Ernstsson    schedule 03.11.2017    source источник


Ответы (1)


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

Этот риск можно уменьшить, убедившись, что «аудитория» отправляется в токене, который идентифицирует предполагаемого получателя/арендатора, и убедившись, что получатели действительно подтверждают это значение аудитории, но вы будете зависеть — даже больше. - на правильную реализацию у получателя, которую трудно обеспечить.

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

FWIW: тот же аргумент справедлив для повторного использования ключей: это усложняет защиту от «перекрестной игры».

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

person Hans Z.    schedule 03.11.2017