시작하기 전에 이 페이지 위쪽의 정책 유형 선택 선택기를 사용하여 설정하려는 정책 유형을 선택합니다. Azure Active Directory B2C는 미리 정의된 사용자 흐름 또는 완전히 구성 가능한 사용자 지정 정책을 통해 사용자가 애플리케이션과 상호 작용하는 방법을 정의하는 두 가지 방법을 제공합니다. 이 문서에서 필요한 단계는 각 방법마다 다릅니다.
이 문서에서는 Azure AD B2C(Azure Active Directory B2C) 서비스의 사용 제약 조건 및 기타 서비스 제한에 대해 간략하게 설명합니다. 이러한 제한은 위협 요소를 효과적으로 관리하고 높은 수준의 서비스 품질을 보장하여 고객을 보호하기 위해 적용됩니다.
Note
이 문서에 언급된 서비스 제한을 늘리려면 지원에 문의하세요.
사용자/사용량 관련 제한
Azure AD B2C 테넌트를 통해 인증할 수 있는 사용자 수는 요청 제한을 통해 관리됩니다. 다음 표에는 Azure AD B2C 테넌트의 요청 제한이 정리되어 있습니다.
| Category | Limit |
|---|---|
| Azure AD B2C 테넌트당 IP별 최대 요청 수 | 6,000/5min |
| Azure AD B2C 테넌트당 최대 요청 수 | 200/sec |
엔드포인트 요청 사용
Azure AD B2C는 OAuth 2.0, OIDC(OpenID Connect) 및 SAML 프로토콜을 준수합니다. 다음 표에 나열된 엔드포인트를 통해 사용자 인증 및 SSO(Single Sign-On) 기능을 제공합니다.
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 |
| 페더레이션된 ID 공급자 | 2 |
사용자 흐름의 초당 토큰 발급률을 구하는 방법은 다음과 같습니다.
- 위의 표를 사용하여 동적 엔드포인트에서 소비된 총 요청 수를 더합니다.
- 애플리케이션 유형에 따라 정적 엔드포인트에서 예상되는 요청 수를 더합니다.
- 아래 수식을 사용하여 초당 토큰 발급률을 계산합니다.
Tokens/sec = 200/requests-consumed
사용자 지정 정책의 토큰 발급률은 정적 엔드포인트와 동적 엔드포인트에서 소비하는 요청 수에 따라 달라집니다. 아래 표에는 동적 엔드포인트에서 Azure AD B2C 스타터 팩에 소비하는 요청 수가 정리되어 있습니다.
| 스타터 팩 | Scenario | 사용자 경험 ID | 사용된 요청 |
|---|---|---|---|
| LocalAccounts | Sign-in | SignUpOrSignIn | 2 |
| LocalAccounts SocialAndLocalAccounts | Sign-up | SignUpOrSignIn | 6 |
| LocalAccounts | 프로필 편집 | ProfileEdit | 2 |
| LocalAccounts 소셜AndLocalAccounts 소셜AndLocalAccountsWithMfa | 암호 재설정 | 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 |
| 페더레이션된 ID 공급자 | 2 |
사용자 지정 정책의 초당 토큰 발급률을 구하는 방법은 다음과 같습니다.
- 위의 표를 사용하여 동적 엔드포인트에서 소비되는 총 요청 수를 계산합니다.
- 애플리케이션 유형에 따라 정적 엔드포인트에서 예상되는 요청 수를 더합니다.
- 아래 수식을 사용하여 초당 토큰 발급률을 계산합니다.
Tokens/sec = 200/requests-consumed
모범 사례
다음 구성 옵션을 고려하여 토큰 발급률을 최적화할 수 있습니다.
- 액세스 및 새로 고침 토큰 수명 늘리기
- Azure AD B2C 웹 세션 수명을 늘립니다.
- 로그인 유지를 사용합니다.
- API의 OpenId Connect 메타데이터 문서를 캐싱합니다.
- 조건부 액세스를 사용하여 조건부 MFA 적용
Azure AD B2C 구성 제한
다음 표에서는 Azure AD B2C 서비스의 관리 구성 제한을 나열합니다.
| Category | Limit |
|---|---|
| 애플리케이션당 범위 수 | 1000 |
| 사용자당 사용자 지정 특성수 1 | 100 |
| 애플리케이션당 리디렉션 URL 수 | 100 |
| 애플리케이션당 로그아웃 URL 수 | 1 |
| 특성당 문자열 제한 | 문자 250개 |
| 구독당 B2C 테넌트 수 | 20 |
| 테넌트당 개체 수(사용자 계정 및 애플리케이션) (기본 제한) 2 | 125만 명 |
| 테넌트당 개체 수(사용자 계정 및 애플리케이션)(확인된 사용자 지정 도메인 사용) 3. 이 제한을 늘리려면 Microsoft 지원에 문의하세요. | 525만 명 |
| 일본 Go-Local Azure AD B2C 테넌트당 개체 수(기본 제한) 4 | 310K |
| 일본 Go-Local Azure AD B2C 테넌트에 대한 테넌트당 개체 수(확인된 사용자 지정 도메인 사용) 5. 이 제한을 늘리려면 Microsoft 지원에 문의하세요. | 570K |
| 사용자 지정 정책의 상속 수준 | 10 |
| Azure AD B2C 테넌트당 정책 수(사용자 흐름 + 사용자 지정 정책) | 200 |
| 최대 정책 파일 크기 | 1024KB |
| 테넌트당 API 커넥터 수 | 20 |
- 1Microsoft Entra 서비스 제한 사항 및 제한 사항도 참조하세요.
- 2 1M 사용자 계정 및 250K 애플리케이션.
- 3 5M 사용자 계정 및 250K 애플리케이션.
- 4 60K 사용자 계정 및 250K 애플리케이션.
- 5 320K 사용자 계정 및 250K 애플리케이션.
지역 특정 서비스 제한
Microsoft는 고객을 보호하기 위해 특정 지역 코드에 대한 전화 통신 확인에 몇 가지 제한을 줍니다. 다음 표에서는 지역 코드와 해당 제한을 나열합니다. 이러한 제한은 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의 제한 지침에 대해 알아보기
- Azure AD B2C 애플리케이션의 유효성 검사 차이점에 대해 알아보기
- 개발자 모범 사례를 통한 복원력에 대해 알아보기