OIDC: у нескольких органов власти один и тот же эмитент?
У нас есть мультитенантное решение для открытого идентификатора сервера идентификации с каждым арендатором / клиентом, который в настоящее время имеет свой собственный адрес авторизации и информацию метаданных. Мы используем одни и те же ключи, чтобы подписать JWTS для всех арендаторов. Пример URL-адреса полномочий для одного клиента: https://auth.ourdomain.com/tenant123. (причина историческая и не очень легко изменить)
Несмотря на то, что нам нужны разные URL авторизации для каждого арендатора, мы бы предпочли как можно больше простоты при проверке подписанного jwts при создании внутреннего apis и для третьих лиц. В настоящее время URI эмитента также специфичен для каждого арендатора, но мы думаем об изменении этого, чтобы все арендаторы использовали один и тот же URI эмитента, и, таким образом, проверка подлинности JWT могла быть проведена для URI с фиксированными полномочиями.
Помимо зависимости от того, что все органы должны иметь одни и те же подписывающие jwks, есть ли какие-либо опасения по поводу того, что несколько органов власти совместно используют один и тот же эмитент, когда речь идет о безопасности, спецификации или просто рекомендуемой наилучшей практике?
1 ответ
В целом, я бы не рекомендовал использовать одного и того же эмитента, поскольку это увеличивает риск повторного использования токенов между арендаторами, т. Е. Пользователь одного арендатора выдает себя за другого пользователя другого арендатора.
Можно уменьшить этот риск, убедившись, что в токене отправлена "аудитория", идентифицирующая предполагаемого получателя / арендатора, и убедившись, что получатели действительно проверяют ценность этой аудитории, но вы будете зависеть - даже больше - от правильной реализации на получатель, что сложно обеспечить.
Другой мерой, которая уменьшит риск, является обеспечение уникальности идентификаторов пользователей для всех арендаторов, но это также сложно обеспечить.
FWIW: тот же аргумент верен для повторного использования ключей: это усложняет защиту от "перекрестной игры".
Примечание: в принципе повторное использование ключей также затрудняет переключение клавиш (и избегает подхода большого взрыва для всех арендаторов), но в ключах OIDC вы, вероятно, используете jwks_uri для этого в любом случае, который автоматизирует вещи на основе проверки сертификата сервера TLS.