Oauth2: поставщик данных с несколькими OpenId-провайдерами

Question

Представьте себе DataProvider, защищенный OAuth2.Этот DataProvider принимает токены OAuth2 от нескольких поставщиков OpenId.Когда RP (клиент) вызывает этот DataProvider с токеном доступа, как DataProvider может знать, что DataProvider должен связаться для проверки токена доступа?

Answer 1

OAuth 2.0 был разработан для мира, где Ресурсный сервер (RS, который вы называете DataProvider) и Сервер авторизации (AS, который вы называете OpenID Provider) находятся в одном домене безопасности.

Использование подсказок для поиска AS из нескольких AS является нестандартным поведением.Предполагая, что все AS будут использовать один и тот же тип токена доступа, формат и утверждения, например, области видимости также растянуты.UMA 2.0, профиль Auth 2.0 на самом деле может помочь здесь https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html, но не получил широкого распространения.

Лучший архитектурный подход состоит в настройке сервера AS в вашем домене, который выдает ключ доступа, отключенныйудаленных ASES.

В качестве альтернативы вы можете реализовать профиль OpenID Connect OAuth 2.0, уровня идентификации поверх OAuth 2.0, который допускает установки с несколькими провайдерами, поскольку в id_token указано, кто является эмитентом, iss заявка, ссылка на поставщика и взаимодействие с так называемой конечной точкой UserInfo в домене поставщика была стандартизирована.

Answer 2

Целесообразно создать бэкэнд, который может принимать токены OAuth от нескольких эмитентов. Для этого вам нужен слой для фильтрации запросов и проверки токенов доступа. Если вы из JAVA EE, подумайте, что это фильтр, который защищает все конечные точки, защищенные OAuth (например, сервлеты).

Выбор сервера авторизации (сторона, выдавшая токен OAuth) может быть выполнен несколькими способами.

Во-первых, отправитель запроса (вероятно, клиент) может передать подсказку с маркером OAuth поставщику данных. Для этого вы можете использовать выделенный заголовок с предварительным соглашением с клиентами и поставщиком данных (на стороне сервера). Например, auth-source:azure-ad для обозначения OAuth-токена был выдан сервером авторизации рекламы Azure. Обратите внимание, что при таком подходе вам также необходимо согласовать поддерживаемые значения заголовков.

Вторым является обнаружение сервера авторизации через претензию эмитента (iss претензия). Для этого ваш токен доступа должен быть в формате JWT. В соответствии с текущей ситуацией, многие сервисы выдают токены доступа в формате JWT (например: A zure AD делает это ). JWT, являющийся автономным токеном, должен содержать утверждение iss, обозначающее издателя JWT , сервер авторизации.