Прием токенов с нескольких серверов авторизации

Question

Во время обучения OpenID Connect в следующем сценарии возникли некоторые вопросы. Большая часть документации, доступной в Интернете об OIDC / OAuth, предполагает, что к серверу ресурсов можно обращаться только от клиента в пределах одной и той же «области авторизации», что означает, что клиент и все серверы ресурсов защищены одним и тем же провайдером OID C (OP).

В данном сценарии Клиент защищен OP A и требует, чтобы Пользователь A вошел в систему на OP A, прежде чем сможет использовать Клиент. Таким образом, Клиент также получает токен доступа от OP A, который позволяет ему получать доступ к серверу ресурсов A от имени пользователя. Пока все хорошо.

Пользователь A также имеет учетную запись в области авторизации B, и клиент должен получить доступ к серверу ресурсов B, который защищен OP B.

Этот сервер ресурсов B API, который вызывает другие API в той же области авторизации B. Все эти API / серверы ресурсов ничего не знают о OID C Провайдеры за пределами своей собственной области авторизации B. Сервер ресурсов B не может быть доступен только из клиента из области A , но также из N клиентов из различных областей авторизации. В моем текущем понимании, все серверы ресурсов в области B должны принимать токены от различных OP.

Это будет означать:

• Большая конфигурация во всех API
• Каждый раз, когда добавляется или удаляется новая область, конфигурация должна обновляться для всех API

Я понимаю, что Клиент A может получить два токена доступа. Один из OP A и один из OP B. Общие библиотеки авторизации не поддерживают это «из коробки», и это увеличило бы сложность, с которой клиент должен справиться (управление / обновление нескольких токенов / отправка правильного токена в нужную конечную точку). Кроме того, мне не ясно, как будет выглядеть поток OID C при работе с двумя токенами из двух OP.

1. Клиент перенаправляет пользователя на OP A для аутентификации (поскольку Сам клиент защищен OP A).
2. После получения идентификатора и токена доступа пользователю разрешено использовать клиент, и у клиента есть необходимый токен для API A.
3. Клиент будет также запросите токен доступа у OP B, что означает, что пользователь должен пройти аутентификацию на OP B
4. . Пользователь должен будет либо указать имя пользователя / пароль на OP B, либо, если мы используем федерацию идентификации, OP B перенаправит на OP A, где у пользователя уже есть сеанс, в результате чего получается токен доступа из OP B для API B
5. . Клиент будет использовать токен B для вызовов API B и токен A для вызовов API A

Существуют ли другие решения для приема запросов от Клиентов, защищенных другим OP с использованием OAuth / OID C? Очевидно, что между двумя сферами должна быть какая-то установка доверия. Но как этого достичь, не затрагивая все серверы ресурсов в области B?

Answer 1

Самый простой вариант имеет тенденцию включать федеративную аутентификацию:

• Пользователь в области A использует пользовательский интерфейс, принадлежащий области B
• Пользовательский интерфейс перенаправляет на Realm B OID C поставщик
• Пользовательский интерфейс перенаправляет далее к OID-провайдеру Realm A C провайдера
• Пользователь аутентифицируется с помощью учетных данных Realm A
• Токен Realm A отправляется поставщику OID C Realm B
• Маркер области B возвращается в пользовательский интерфейс
• Пользовательский интерфейс отправляет токен области B в API области B

Это само по себе имеет довольно дорогие предварительные условия, включая доверие должно быть настроено между поставщиками Realm B и OID C. После завершения кода в пользовательском интерфейсе и API-интерфейсах все довольно просто, и обязанности распределяются по нужным местам.

Другие варианты, такие как разрешение входа в систему в области A, затем вызов API-интерфейсов как в области A, так и в области B, часто невозможно реализовать это на практике.

Многие люди хотят делать подобные вещи, и, возможно, новые стандарты, такие как JWT Bearer Token Exchange , помогут в предстоящей паре года.