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

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

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

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

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

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

1. Клиентское приложение получает маркер доступа для вызова исходного API. Клиентское приложение получает токен доступа делегированного разрешения к исходному API. Маркер доступа делегированного разрешения позволяет ему работать от имени пользователя, чтобы вызвать исходный API, требующий авторизации.
2. Клиентское приложение предоставляет маркер доступа к исходному API. Клиентское приложение предоставляет маркер доступа исходному API. Исходный API полностью проверяет и проверяет маркер доступа, чтобы определить удостоверение пользователя клиентского приложения.
3. Исходный API выполняет валидацию токенов и обеспечение выполнения. После того как клиентское приложение передает токен доступа в исходный API, исходный API выполняет проверку токена и его применение. Если все хорошо, API продолжает и обслуживает запрос клиентского приложения.
4. Исходный API не может использовать токен доступа для вызова вторичного API. Исходный API хочет вызвать API нижнего уровня. Однако исходный API не может использовать маркер доступа для вызова нижестоящего API.
5. Исходный API возвращается к идентификатору Microsoft Entra. Исходный API должен вернуться к идентификатору Microsoft Entra. Он должен иметь маркер доступа для вызова НИЖЕстоящего API от имени пользователя. Исходный API предоставляет токен, который он получил от клиентского приложения, а также свои учетные данные.
6. Идентификатор Microsoft Entra выполняет проверки. Идентификатор Microsoft Entra проверяет наличие таких элементов, как согласие или принудительное применение условного доступа. Возможно, вам придется вернуться к вызывающей клиенту и указать причину, по которой не удается получить маркер. Обычно вы используете процесс вызова утверждений, чтобы вернуться в вызывающее приложение с информацией о том, что согласие не получено (например, связано с политиками условного доступа). Если все в порядке, идентификатор Microsoft Entra выдает маркер доступа к исходному API для вызова НИЖЕстоящего API от имени пользователя.
7. Оригинальный API имеет пользовательский контекст с потоком On-Behalf-Of. Процесс On-Behalf-Of flow (OBO) позволяет API продолжать использовать контекст пользователя при обращении к API ниже по потоку.
8. Исходный API вызывает подчиненный API. Вызовите downstream 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. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• Защищенные пользовательские API с помощью модуля Microsoft Identity Learn объясняют, как защитить веб-API с помощью удостоверения Майкрософт и как вызвать его из другого приложения.
• Рекомендации по безопасности свойств приложения описывают URI перенаправления, маркеры доступа, сертификаты и секреты, URI идентификатора приложения и владение приложением.
• платформа удостоверений Майкрософт библиотеках проверки подлинности описывает поддержку библиотеки проверки подлинности Майкрософт для различных типов приложений.