Today all app registrations in B2C is registered as Enterprise Applications and are available for any AzureAD tenants. The consequence of this is that users from any teneant can create themself a access token that is valid for a application registered in B2C (resource/scope can be set to a resource outside own tenant). In many scenarios this poses a security challange as we in most cases want full control of which identities that can be authentication and granted access to own applications. This must be addressed when B2C support client_credential flow and on-behalf of flow. Please add an option for us to choose if the app registration in B2C should be regular (local to own tenant) or enterprise (available to all tenants).

I am working on ui customization. I have styled div id=email_ver_wait element. It appears when the user clicks verify code button and disappears when the verification process is done. But, when the user enters wrong verification code three times the element is permanently visible.

Steps to reproduce:
1. Run "sign-up or sing-in" policy
2. Click "sign-up now" link
3. Enter any valid e-mail address.
4. Click "Send verification code"
5. Enter invalid code and click "Verify code" button
6. Repeat step 5 until "
You've made too many incorrect attempts. Please try again later" message appears.
7. bug: email_ver_wait element is visible:
<div id="email_ver_wait" class="working" aria-hidden="false" style="display: inline;" role="alert" aria-live="polite"></div>

Summary:
When customer focus to E-mail address field on B2C Sign-In page, Japanese IME turns ON automatically. However, E-mail address is single byte character, it should not turn on automatically.
This behavior caused lots of login user makes mistake typing during Sign-In and Sign-Up (also, password recovery).

Preparation Step for repro environment:

1. Go to the blade "https://portal.azure.com/#blade/Microsoft_AAD_B2CAdmin/TenantManagementMenuBlade/policiesB2CSignUpOrSignIn".
2. Edit your SignUp/SingIn policy
3. Go to Language Customization (Preview)
4. Add Language "Japanese".
5. Save.

Repro Step:

1. Access to B2C Sign-In page via Japanese Windows 10 Edge browser.
2. Focus on E-mail address field.

Result:
Japanese IME is ON. (Enter the double byte character mode, but E-mail address is single byte character)

3. Focus on Password field. Japanese IME is OFF (this is correct behavior)
4. Focus on E-mail address field again. Japanese IME is ON.(this is wrong behavior)

Expected Result:
Japanese IME should not turn on when focus on E-mail address filed.

Plugging in ADB2C to an existing MVC website breaks all of the forms that should use ValidateAntiForgeryToken attributes.

Whilst the work-around is relatively easy, it should support it out of the box by exposing the additional claim type.

A claim of type 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier'; or 'http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider'; was not present on the provided ClaimsIdentity. To enable anti-forgery token support with claims-based authentication, please verify that the configured claims provider is providing both of these claims on the ClaimsIdentity instances it generates. If the configured claims provider instead uses a different claim type as a unique identifier, it can be configured by setting the static property AntiForgeryConfig.UniqueClaimTypeIdentifier.

I am working for a client that has multiple applications pointing to the tenant, but require different UI screens. In order to do this, I have to make duplicate policies that point to different HTML pages for the content definitions. If I could pass a parameter that provided a directory on where to find the corresponding HTML then it would help manage policies in the portal and their files across applications and environments. Also, this will help provide a separation of concerns where the policy (functionality) is not directly linking to the UI pages on how the content is presented to the user.

As an example, right now I have 5 policy files per application. By next year, I could have 4 applications. If I had this capability, I could manage 5 policy files in the portal instead of 20.

This all assumes that the functional logic will be the same. If I wanted to create another set of policy files to handle different logic then I could potentially double the numbers above.