Как вы, как разработчик, убедитесь, что у вас есть один 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, будет иметь соответствующее утверждение аудитории (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, защищенный платформой согласия на идентификацию Майкрософт, помогает разрабатывать стратегии с минимальными привилегиями приложений для оптимального взаимодействия с пользователем.
Рекомендации по безопасности для свойств приложения описывают URI перенаправления, маркеры доступа (используемые для неявных потоков), сертификаты и секреты, URI идентификатора приложения и владение приложением.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
