Вызов API из другого API

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

Когда пользователь управляет пользовательским интерфейсом приложения, приложение может использовать делегированное разрешение, чтобы API знал, какой пользователь от имени приложения работает. Он проверял утверждения субъекта (вложенные) или идентификатор объекта (oid) и утверждения идентификатора клиента (tid) в маркере доступа, который приложение предоставляет при вызове API. API не будет полагаться на ненадежное приложение, которое является просто вызовом, поступающим откуда-то в сети. Вместо этого он проверяет маркер, чтобы убедиться, что API работает только от имени пользователя приложения, проверенного идентификатором Microsoft Entra.

Когда один API (мы называем его исходным API) вызывает другой, важно, чтобы API, который мы вызываем (мы называем его подчиненным API) следует описанному выше процессу проверки. Нижестоящий API не может полагаться на ненадежный сетевой источник. Он должен получить удостоверение пользователя из правильно проверенного маркера доступа.

Если подчиненный API не соответствует правильному процессу проверки, то подчиненный API должен полагаться на исходный API, чтобы предоставить удостоверение пользователя другим способом. Нижестоящий API может неправильно использовать разрешение приложения для выполнения операции. Затем исходный API станет единственным органом, над которым пользователи могли бы достичь каких результатов в отношении нижестоящего API. Исходный API может намеренно (или непреднамеренно) разрешить пользователю выполнять задачу, которую пользователь не мог выполнить в противном случае. Например, один пользователь может изменить сведения другого пользователя или прочитать и обновить документы, которым у пользователя нет разрешения на доступ. Неправильная проверка может вызвать серьезные проблемы с безопасностью.

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

Клиентское приложение получает маркер доступа для вызова исходного API

На следующей схеме показаны клиентское приложение и исходный API.

Заголовок схемы: клиентское приложение получило маркер доступа для вызова исходного API. Подзаголовок схемы: клиентское приложение имеет маркер A, который позволяет ему работать от имени пользователя, определенного в маркере для вызова исходного API.

Клиентское приложение приобрело маркер доступа к делегированным разрешениям (указанный фигурой пентагона с меткой A) исходному API. Маркер доступа делегированного разрешения позволяет ему работать от имени пользователя, чтобы вызвать исходный API, требующий авторизации.

Клиентское приложение предоставляет маркер доступа к исходному API

Следующая анимация показывает клиентское приложение, предоставляющее маркер доступа исходному API. Исходный API полностью проверяет и проверяет маркер доступа, чтобы определить удостоверение пользователя клиентского приложения.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Название первой схемы: клиентское приложение получило маркер доступа для вызова исходного API. Подзаголовок первой схемы: клиентское приложение имеет маркер A, который позволяет ему работать от имени пользователя, определенного в маркере для вызова исходного API. Второй заголовок схемы: клиентское приложение предоставляет маркер доступа к исходному API.

Исходный API выполняет проверку маркеров и принудительное применение

Следующая анимация показывает, что после того, как клиентское приложение предоставляет маркер доступа к исходному API, исходный API выполняет проверку маркеров и принудительное применение. Если все хорошо, API продолжает и обслуживает запрос клиентского приложения.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Название первой схемы: клиентское приложение предоставляет маркер доступа к исходному API. Второй заголовок схемы: Исходный API выполняет проверку маркеров и принудительное применение. Если все хорошо, API продолжает и обслуживает запрос.

Исходный API не может использовать маркер доступа для вызова НИЖЕстоящего API

В следующей анимации показано, что исходный API теперь хочет вызвать подчиненный API. Однако исходный API не может использовать маркер доступа для вызова нижестоящего API.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: Исходный API хочет вызвать подчиненный API. Второй заголовок схемы: исходный API не может использовать маркер для вызова НИЖЕстоящего API.

Исходный API возвращается к идентификатору Microsoft Entra

В следующей анимации исходный API должен вернуться к идентификатору Microsoft Entra. Он должен иметь маркер доступа для вызова НИЖЕстоящего API от имени пользователя.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: исходный API не может использовать маркер для вызова нижестоящего API. Второй заголовок схемы: исходный API возвращается к идентификатору Microsoft Entra. Второй подзаголовок схемы: требуется маркер доступа для вызова НИЖЕстоящего API от имени пользователя.

Следующая анимация показывает исходный API, предоставляющий маркер, полученный исходным API от клиентского приложения и учетных данных клиента ИСХОДНОго API.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: исходный API возвращается к идентификатору Microsoft Entra. Подзаголовок первой схемы: требуется маркер доступа для вызова НИЖЕстоящего API от имени пользователя. Второй заголовок схемы: исходный API возвращается к идентификатору Microsoft Entra. Второй подзаголовок схемы: предоставляет маркер из клиентского приложения и учетные данные для исходного API.

Идентификатор Microsoft Entra проверяет наличие таких элементов, как согласие или принудительное применение условного доступа. Возможно, вам придется вернуться к вызывающей клиенту и указать причину, по которой не удается получить маркер. Обычно вы используете процесс вызова утверждений, чтобы вернуться в вызывающее приложение с информацией о том, что согласие не получено (например, связано с политиками условного доступа).

Идентификатор Microsoft Entra выполняет проверки

В следующей анимации идентификатор Microsoft Entra выполняет свои проверки. Если все в порядке, идентификатор Microsoft Entra выдает маркер доступа к исходному API для вызова НИЖЕстоящего API от имени пользователя.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: исходный API возвращается к идентификатору Microsoft Entra. Подзаголовок первой схемы: предоставляет маркер из клиентского приложения и учетные данные для исходного API. Второй заголовок схемы: идентификатор Microsoft Entra проверяет условный доступ, согласие и т. д. Второй подзаголовок схемы: Исходный API получает свой собственный маркер доступа для вызова НИЖЕстоящего API от имени пользователя, выполнившего вход в клиентское приложение.

Исходный API имеет контекст пользователя с потоком On-Behalf-Of

Следующая анимация иллюстрирует процесс потока On-Behalf-Of (OBO), который позволяет API продолжать иметь контекст пользователя при вызове НИЖЕстоящего API.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: процесс потока on-Behalf-Of позволяет исходному API продолжать иметь контекст пользователя при вызове НИЖЕстоящего API. Второй заголовок схемы: процесс потока on-Behalf-Of позволяет исходному API продолжать иметь контекст пользователя при вызове НИЖЕстоящего API.

Исходный API вызывает подчиненный API

В следующей анимации мы вызываем ПОДЧИНЕННЫЙ API. Маркер, получаемый НИЖЕстоящим API, имеет соответствующее утверждение аудитории (aud), указывающее подчиненный API.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: процесс потока on-Behalf-Of позволяет исходному API продолжать иметь контекст пользователя при вызове НИЖЕстоящего API. Второй заголовок схемы: вызывается нижестоящий API. Второй подзаголовок схемы: маркер, который получает подчиненный API, имеет правильные утверждения для идентификации пользователя клиентского приложения.

Маркер включает области предоставления согласия и исходное удостоверение пользователя приложения. API нижестоящего потока может правильно реализовать действующие разрешения, чтобы убедиться, что указанный пользователь имеет разрешение на выполнение запрошенной задачи. Вы хотите использовать поток от имени для получения маркеров для API для вызова другого API, чтобы убедиться, что контекст пользователя передается всем нижестоящим API.

Лучший вариант: исходный API выполняет поток on-Behalf-Of

Эта последняя анимация показывает, что оптимальным вариантом является исходный API для выполнения потока On-Behalf-Of (OBO). Если подчиненный API получает правильный маркер, он может правильно реагировать.

На анимированной схеме показаны две схемы с переходом движения между первой и второй диаграммой. Заголовок первой схемы: вызывается нижестоящий API. Подзаголовок первой диаграммы: маркер, который получает подчиненный API, имеет правильные утверждения для идентификации пользователя клиентского приложения. Второй заголовок схемы: лучший вариант — для исходного API выполнять "от имени потока". Если подчиненный API получает правильный маркер, он может правильно реагировать.

Если API действует от имени пользователя и должен вызывать другой API, API должен использовать OBO для получения маркера доступа делегированного разрешения для вызова API-интерфейса внизу от имени пользователя. API никогда не должны использовать разрешения приложения для вызова API-интерфейсов Downstream, когда API действует от имени пользователя.

Следующие шаги

• платформа удостоверений Майкрософт потоки проверки подлинности и сценарии приложений описывают потоки проверки подлинности и сценарии приложения, в которых они используются.
• Защита API описывает рекомендации по защите API путем регистрации, определения разрешений и согласия и принудительного доступа к достижению целей нулевого доверия.
• Пример API, защищенный платформой согласия на идентификацию Майкрософт, помогает разрабатывать стратегии с минимальными привилегиями приложений для оптимального взаимодействия с пользователем.
• Настройка маркеров описывает сведения, которые можно получить в токенах Microsoft Entra. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Защищенные пользовательские API с помощью модуля Microsoft Identity Learn объясняют, как защитить веб-API с помощью удостоверения Майкрософт и как вызвать его из другого приложения.
• Рекомендации по безопасности для свойств приложения описывают URI перенаправления, маркеры доступа (используемые для неявных потоков), сертификаты и секреты, URI идентификатора приложения и владение приложением.
• платформа удостоверений Майкрософт библиотеках проверки подлинности описывает поддержку библиотеки проверки подлинности Майкрософт для различных типов приложений.