Устойчивые интерфейсы с внешними процессами с помощью Azure AD B2C
В этой статье описано, как спланировать и реализовать API RESTful, чтобы сделать приложение более устойчивым к сбоям API.
Обеспечение правильного размещения API
Используйте политики интерфейса идентификации (IEF) для вызова внешней системы с помощью технического профиля API RESTful. Среда выполнения IEF не управляет внешними системами, что является потенциальной точкой сбоя.
Управление внешними системами с помощью API
При вызове интерфейса для доступа к определенным данным подтвердите, что данные определяют решение проверки подлинности. Оцените, является ли информация важной для функциональных возможностей приложения. Например, электронная коммерция и дополнительные функции, например администрирование. Если сведения не нужны для проверки подлинности, рассмотрите возможность перемещения вызова в логику приложения.
Если данные для проверки подлинности являются относительно статическими и небольшими и не должны быть внешними, поместите их в каталог.
По возможности удалите вызовы API из предварительно отступного пути. Если вы не можете, включите защиту от атак типа "отказ в обслуживании" (DoS) и распределенных атак типа "отказ в обслуживании" (DDoS) для API. Злоумышленники могут загрузить страницу входа и попытаться потопить API атаками DoS, чтобы отключить приложение. Например, используйте полностью автоматизированный открытый тест Turing, чтобы сообщить компьютерам и людям отдельно (CAPTCHA) в потоке входа и регистрации.
Используйте соединители API потоков пользователей регистрации для интеграции с веб-API после объединения с поставщиком удостоверений, во время регистрации или перед созданием пользователя. Так как тестируются потоки пользователей, вам не нужно выполнять функциональное, производительность или масштабирование. Тестирование приложений для функциональных возможностей, производительности и масштабирования.
Технические профили API RESTful в Azure AD B2C не предоставляют никакого поведения кэширования. Вместо этого профиль API RESTful реализует логику повторных попыток и время ожидания, встроенное в политику.
Для API, которые должны записывать данные, используйте задачу для выполнения этих действий фоновой рабочей ролью. Используйте такие службы, как очереди Azure. Эта практика эффективно возвращает API и повышает производительность выполнения политики.
Ошибки API
Так как API живут вне системы Azure AD B2C, включите обработку ошибок в техническом профиле. Убедитесь, что пользователи проинформированы, и приложение может справиться с ошибкой корректно.
Обработка ошибок API
Так как API-интерфейсы завершаются сбоем по различным причинам, сделайте приложение устойчивым. Если API не может выполнить запрос, возвращается сообщение об ошибке HTTP 4xx. В политике Azure AD B2C попробуйте обработать недоступность API и, возможно, отобразить сокращенный интерфейс.
Выполните правильную обработку временных ошибок. Используйте профиль API RESTful для настройки сообщений об ошибках для различных разбиений цепи.
Мониторинг и использование непрерывной интеграции и непрерывной доставки (CICD). Смена учетных данных доступа к API, таких как пароли и сертификаты, используемые обработчиком технического профиля.
Рекомендации по управлению API
При развертывании REST API и настройке технического профиля RESTful используйте следующие рекомендации, чтобы избежать распространенных ошибок.
Управление API
Управление API (APIM) публикует, управляет и анализирует API. APIM обрабатывает проверку подлинности для безопасного доступа к внутренним службам и микрослужбам. Используйте шлюз API для горизонтального увеличения масштаба развертываний API, кэширования и балансировки нагрузки.
Наша рекомендация заключается в том, чтобы получить правильный маркер, а не вызывать несколько раз для каждого API и защитить API API Azure.