Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Прежде чем начать, используйте селектор типа политики в верхней части этой страницы, чтобы выбрать тип политики, которую вы настроите. Azure Active Directory B2C предлагает два метода для определения взаимодействия пользователей с приложениями: с помощью предопределенных потоков user или с помощью полностью настраиваемых политик custom. Действия, которые необходимо выполнить, отличаются для каждого метода.
В этой статье описываются ограничения использования и другие ограничения службы для службы Azure Active Directory B2C (Azure AD B2C). Эти ограничения применяются для защиты за счет эффективного управления угрозами и обеспечения высокого качества обслуживания.
Note
Чтобы увеличить любые ограничения служб, упомянутые в этой статье, обратитесь в службу поддержки.
Ограничения, связанные с пользователями и потреблением
Число пользователей, которые могут пройти проверку подлинности через Azure клиент AD B2C, задается с помощью ограничений запросов. В следующей таблице показаны ограничения запросов для клиента AD B2C Azure.
| Category | Limit |
|---|---|
| Максимальные запросы на IP-адрес на Azure клиент AD B2C | 6,000/5min |
| Максимальные запросы на Azure клиент AD B2C | 200/sec |
Использование запросов в конечной точке
Azure AD B2C соответствует протоколам OAuth 2.0, OpenID Connect (OIDC) и SAML. Она предоставляет функции проверки подлинности и единого входа (SSO) для пользователей, а также конечные точки, перечисленные в таблице ниже.
Частота запросов, сделанных для Azure конечных точек AD B2C, определяет общую возможность выдачи маркеров. Azure AD B2C предоставляет конечные точки, которые используют другое количество запросов. Дополнительные сведения о том, какие конечные точки используются приложением, см. в статье "Протоколы проверки подлинности ".
| Endpoint | Тип конечной точки | Запросы, используемые |
|---|---|---|
| /oauth2/v2.0/authorize | Dynamic | Зависит от 1 |
| /oauth2/v2.0/token | Static | 1 |
| /openid/v2.0/userinfo | Static | 1 |
| /.well-known/openid-config | Static | 1 |
| /discovery/v2.0/keys | Static | 1 |
| /oauth2/v2.0/logout | Static | 1 |
| /samlp/sso/login | Dynamic | Зависит от 1 |
| /samlp/sso/logout | Static | 1 |
1 Тип потока пользователя определяет общее количество запросов, потребляемых при использовании этих конечных точек.
1 Конфигурация пользовательской политики определяет общее количество запросов, потребляемых при использовании этих конечных точек.
Частота выдачи токенов
Каждый тип потока пользователя предусматривает уникальное пользовательское взаимодействие, поэтому количество потребляемых запросов будет разным. Частота выдачи токенов для потока пользователя зависит от количества запросов, потребляемых как статическими, так и динамическими конечными точками. В таблице ниже показано количество запросов, потребляемых в динамической конечной точке для каждого потока пользователя.
| Поток пользователя | Запросы, используемые |
|---|---|
| Регистрация | 6 |
| Войдите в систему. | 4 |
| Сброс пароля | 4 |
| Изменение профиля | 4 |
| Регистрация и вход по телефону | 6 |
При добавлении в поток пользователя дополнительных функций, например многофакторной проверки подлинности, потребляется больше запросов. В таблице ниже показано, сколько дополнительных запросов потребляется, когда пользователь взаимодействует с одной из этих функций.
| Feature | Количество дополнительных потребляемых запросов |
|---|---|
| многофакторная проверка подлинности Microsoft Entra | 2 |
| Отправка одноразового пароля по электронной почте | 2 |
| Возрастная гисть | 2 |
| Федеративный поставщик удостоверений | 2 |
Чтобы узнать частоту выдачи токенов в секунду для потока пользователя, сделайте следующее:
- Используйте приведенные выше таблицы, чтобы добавить общее количество запросов, потребляемых в динамической конечной точке.
- Добавьте количество запросов, ожидаемых в статических конечных точках, в зависимости от типа приложения.
- Для вычисления частоты выдачи токенов в секунду используйте следующую формулу.
Tokens/sec = 200/requests-consumed
Частота выдачи токенов для пользовательской политики зависит от количества запросов, потребляемых как статическими, так и динамическими конечными точками. В следующей таблице показано количество запросов, потребляемых в динамической конечной точке для < начальных пакетов AD B2C>Azure AD B2C.
| Начальный пакет | Scenario | Идентификатор пути взаимодействия пользователя | Запросы, используемые |
|---|---|---|---|
| LocalAccounts | Sign-in | SignUpOrSignIn | 2 |
| LocalAccounts SocialAndLocalAccounts | Sign-up | SignUpOrSignIn | 6 |
| LocalAccounts | Изменение профиля | ProfileEdit | 2 |
| LocalAccounts SocialAndLocalAccounts SocialAndLocalAccountsWithMfa | Сброс пароля | PasswordReset | 6 |
| SocialAndLocalAccounts | Вход в федеративную учетную запись | SignUpOrSignIn | 4 |
| SocialAndLocalAccounts | Регистрация федеративной учетной записи | SignUpOrSignIn | 6 |
| SocialAndLocalAccountsWithMfa | Вход в локальную учетную запись с использованием MFA | SignUpOrSignIn | 6 |
| SocialAndLocalAccountsWithMfa | Регистрация локальной учетной записи с использованием MFA | SignUpOrSignIn | 10 |
| SocialAndLocalAccountsWithMfa | Вход в федеративную учетную запись с использованием MFA | SignUpOrSignIn | 8 |
| SocialAndLocalAccountsWithMfa | Регистрация федеративной учетной записи с использованием MFA | SignUpOrSignIn | 10 |
Чтобы узнать частоту выдачи токенов в секунду для определенного пути взаимодействия пользователя, сделайте следующее:
- Используйте приведенную выше таблицу, чтобы узнать количество запросов, использованных для пути взаимодействия пользователя.
- Добавьте количество запросов, ожидаемых в статических конечных точках, в зависимости от типа приложения.
- Для вычисления частоты выдачи токенов в секунду используйте следующую формулу.
Tokens/sec = 200/requests-consumed
Вычисление частоты выдачи токенов для пользовательской политики
Вы можете создать собственную пользовательскую политику, чтобы обеспечить уникальную проверку подлинности для своего приложения. Количество запросов, потребляемых в динамической конечной точке, зависит от того, с какими функциями взаимодействует пользователь согласно пользовательской политике. В таблице ниже показано, сколько запросов используется для каждой функции в пользовательской политике.
| Feature | Запросы, используемые |
|---|---|
| Технический профиль для самоподтверждения | 2 |
| Технический профиль для проверки по телефону | 4 |
| Проверка по электронной почте (Verified.Email) | 2 |
| Элемент управления "Отображение" | 2 |
| Федеративный поставщик удостоверений | 2 |
Чтобы узнать частоту выдачи токенов в секунду для пользовательской политики, сделайте следующее:
- Используйте приведенные выше таблицы, чтобы вычислить общее количество запросов, потребляемых в динамической конечной точке.
- Добавьте количество запросов, ожидаемых в статических конечных точках, в зависимости от типа приложения.
- Для вычисления частоты выдачи токенов в секунду используйте следующую формулу.
Tokens/sec = 200/requests-consumed
Лучшие практики
Вы можете оптимизировать частоту выдачи токенов, рассмотрев следующие параметры конфигурации:
- Увеличение времени существования маркера доступа и обновления.
- Увеличение времени существования сеанса Azure AD B2C web session.
- Включение возможности оставаться в системе.
- Кэширование документов метаданных OpenID Connect в ваших API.
- Принудительное применение условной MFA с помощью условного доступа.
Azure ограничения конфигурации AD B2C
В следующей таблице перечислены ограничения административной конфигурации в службе AZURE AD B2C.
| Category | Limit |
|---|---|
| Количество областей для каждого приложения | 1000 |
| Количество пользовательских атрибутов на пользователя 1 | 100 |
| Число URL-адресов перенаправления на одно приложение | 100 |
| Количество URL-адресов выхода для каждого приложения | 1 |
| Ограничение длины строки на один атрибут | 250 символов |
| Число клиентов B2C на одну подписку | 20 |
| Количество объектов (учетных записей пользователей и приложений) для каждого клиента (ограничение по умолчанию) 2 | 1,25 миллиона |
| Количество объектов (учетных записей пользователей и приложений) на клиент (с использованием проверенного личного домена) 3. Если вы хотите увеличить это ограничение, обратитесь к Microsoft Support. | 5,25 миллиона |
| Количество объектов для каждого клиента для Японии Go-Local Azure клиентов AD B2C (ограничение по умолчанию) 4 | 310K |
| Количество объектов для каждого клиента для Японии Go-Local Azure клиентов AD B2C (с использованием проверенного личного домена) 5. Если вы хотите увеличить это ограничение, обратитесь к Microsoft Support. | 570K |
| Уровни наследования в настраиваемых политиках | 10 |
| Количество политик на Azure клиент AD B2C (потоки пользователей и пользовательские политики) | 200 |
| Максимальный размер файла политики | 1024 КБ |
| Количество соединителей API для каждого клиента | 20 |
- 1 См. также Microsoft Entra ограничения и ограничения службы.
- 2 учетных записей пользователей 1 млн и 250K приложений.
- 3 5M учетных записей пользователей и 250K приложений.
- 4 60K учетных записей пользователей и 250K приложений.
- 5 учетных записей пользователей 320K и 250K приложений.
Ограничения для конкретной службы в регионе
В качестве защиты для наших клиентов корпорация Майкрософт устанавливает некоторые ограничения на проверку телефонии для определенных кодов регионов. В следующей таблице перечислены коды регионов и соответствующие ограничения. Эти ограничения применяются как к sms, так и к проверке голоса.
| Код Региона | Имя региона | Ограничение на клиент за 60 минут | Ограничение на клиент в 24 часа |
|---|---|---|---|
| 20 | Egypt | 50 | 200 |
| 211 | Южный Судан | 10 | 30 |
| 212 | Morocco | 20 | 100 |
| 213 | Algeria | 20 | 100 |
| 216 | Tunisia | 20 | 100 |
| 221 | Senegal | 10 | 30 |
| 223 | Mali | 20 | 100 |
| 224 | Guinea | 20 | 100 |
| 225 | Берег Слоновой Кости | 10 | 30 |
| 226 | Бурина Фасо | 10 | 30 |
| 228 | Togo | 10 | 30 |
| 233 | Ghana | 10 | 30 |
| 234 | Nigeria | 20 | 100 |
| 235 | Chad | 10 | 30 |
| 236 | Центральноафриканская Республика | 10 | 30 |
| 238 | Кабо-Верде | 10 | 30 |
| 249 | Sudan | 10 | 30 |
| 251 | Ethiopia | 10 | 30 |
| 252 | Somalia | 10 | 30 |
| 255 | Tanzania | 10 | 50 |
| 256 | Uganda | 20 | 100 |
| 257 | Uzbek | 10 | 30 |
| 258 | Mozambique | 50 | 200 |
| 260 | Zambia | 50 | 200 |
| 261 | Madagascar | 10 | 30 |
| 263 | Zimbabwe | 10 | 30 |
| 265 | Malawi | 10 | 30 |
| 266 | Лесото | 10 | 30 |
| 359 | Болгария | 20 | 100 |
| 373 | Moldova | 20 | 100 |
| 375 | Belarus | 10 | 30 |
| 380 | Украина | 50 | 200 |
| 381 | Serbia | 50 | 200 |
| 386 | Slovenia | 10 | 50 |
| 501 | Belize | 10 | 30 |
| 502 | Guatemala | 10 | 50 |
| 503 | Сальвадор | 10 | 30 |
| 504 | Гондурас | 50 | 200 |
| 52 | Mexico | 100 | 500 |
| 53 | Cuba | 10 | 30 |
| 58 | Venezuela | 10 | 30 |
| 591 | Bolivia | 10 | 30 |
| 593 | Эквадор | 20 | 100 |
| 60 | Malaysia | 50 | 200 |
| 62 | Indonesia | 50 | 200 |
| 63 | Philippines | 50 | 200 |
| 670 | Восточный Тимор (Timor-Leste) | 10 | 30 |
| 675 | Папуа-Новая Гвинея | 10 | 30 |
| 7 | Russia | 100 | 1000 |
| 84 | Vietnam | 150 | 500 |
| 855 | Cambodia | 50 | 200 |
| 856 | Laos | 50 | 200 |
| 880 | Bangladesh | 50 | 200 |
| 92 | Pakistan | 100 | 1000 |
| 93 | Afghanistan | 10 | 30 |
| 94 | Шри-Ланка | 100 | 500 |
| 95 | Мьянма (Бирма) | 10 | 30 |
| 961 | Lebanon | 10 | 30 |
| 963 | Syria | 10 | 30 |
| 964 | Iraq | 50 | 200 |
| 965 | Кувейт | 50 | 200 |
| 967 | Yemen | 10 | 30 |
| 970 | Государство Палестина | 10 | 30 |
| 972 | Israel | 50 | 200 |
| 975 | Bhutan | 20 | 100 |
| 976 | Mongolia | 10 | 30 |
| 977 | Nepal | 20 | 100 |
| 992 | Tajikistan | 10 | 30 |
| 993 | Turkmenistan | 10 | 30 |
| 994 | Azerbaijan | 50 | 200 |
| 995 | Georgia | 10 | 30 |
| 996 | Kyrgyzstan | 10 | 30 |
| 998 | Uzbekistan | 10 | 30 |
Дальнейшие шаги
- Узнайте о< руководстве по регулированию
Microsoft Graph/c0> - Сведения о различиях validation для приложений AZURE AD B2C
- Узнайте об устойчивости с помощью рекомендаций разработчика