Вызов 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.

Клиентское приложение приобрело маркер доступа к делегированным разрешениям (указанный фигурой пентагона с меткой A) исходному 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 проверка для таких действий, как согласие или принудительное применение условного доступа. Возможно, вам придется вернуться к вызывающей клиенту и указать причину, по которой не удается получить маркер. Обычно вы используете процесс вызова утверждений, чтобы вернуться в вызывающее приложение с информацией о том, что согласие не получено (например, связано с политиками условного доступа).

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

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

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

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

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

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

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

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

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

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

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

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