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

Как разработчик, как вы обеспечиваете концепцию Zero Trust, если у вас есть один 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 делает вызов. Давайте рассмотрим, как это работает.

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 ID выдает токен доступа оригинальному 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). Если Downstream API получает правильный токен, он сможет ответить корректно. Если API действует от имени пользователя и должен вызывать другой API, API должен использовать OBO для получения маркера доступа делегированного разрешения для вызова API-интерфейса внизу от имени пользователя. API никогда не должны использовать разрешения приложения для вызова API-интерфейсов Downstream, когда API действует от имени пользователя.

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

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