As it's possible in the standard AD by changing the API application manifest option "groupMembershipClaims" to "SecurityGroup", is it possible to return user membership group in the claims with AD B2C?

Now, we can have only the default and custom attributes by adding a signin policy, but it's impossible to get user membership groups.

Currently, Azure AD B2C sends verification codes via emails to end users during sign-up and password reset flows. These emails have limited customization. Add support for full customization of the email body & content.

Lots of Japanese customers would like to use Azure AD B2C. But they can not decide to adopt B2C because we do not have Japan region as data residency location.

AADB2C is great, but why not adding an Azure AD provider? We're developing an application where we can have customers with social identities as well as Azure AD identities, it would be great in the AADB2C login page to have an option like "Organization Account". In this way we can code against one single API and not be forced to use two different entry points.

Run Azure AD B2C's sign-up & sign-in pages under a custom domain, for e.g., login.contoso.com, instead of login.microsoftonline.com.

I would like the ability to trigger an email invitation be sent to new users for our web application that I want to authenticate with AADB2C. In our multi-tenant design, each tenant will be responsible for adding their own users to their tenant. I would like the admin of the tenant to be able to send an email invitation to the new user and then that user can complete the sign-up process.

Create a Sign In Policy by which we can provide our own template for the sign in page. It could work the same way as the Sign Up policy does.

Hi, Assume, I sign up with Google 'siva@gmail.com', it creates a user in the tenant. I sign up with Facebook 'siva@gmail.com', it creates another user in the tenant. Also I went and Sign up using email account, for 'siva@gmail.com', now am finding 3 users with same email id. I see this is a duplicate accounts are getting created. Is there any way this can be validated & inform user in Azure AD B2C ?

Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library, just like Azure AD and Active Directory Authentication Library has.

The Azure AD B2C page has been saying 'Get tokens using a username & password with the OAuth 2.0 Resource Owner Password Credentials Flow (coming soon)' since September 2015.
https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-reference-protocols/

As service provider using Azure as the underlying platform, I want to create an application that allows companies to create and manage their tenants and users within my service in order to provide a public service area as well as a privately owned area for the company.

I've read about B2C supporting multi-tenant, but I couldn't find hints within the documentation...

Azure AD B2C currently supports OpenID Connect and OAuth 2.0. Add SAML protocol support as well.

Add a new Azure AD B2C policy that allows a signed-in user to change his or her password. Not the same as password reset.

Allow support for multiple languages on Azure AD B2C end user pages.

Storm Path is an example of an API/Service that provides all the same functionality as Azure AD B2C, and actually integrates with Spring Security very easily.

https://stormpath.com/

They provide code samples too:

https://docs.stormpath.com/java/

It would be fantastic, and ensure a much wider adoption market, if you were to create an open source project that provided the same easy integration and adoption.

To enable APIs to use authentication from another application with separate security credentials (clientId+secret). Needed for APIs to make graph calls.

Allow the ability to set different password complexities for local accounts in a B2C tenant.

Currently, I can migrate user accounts from an existing database to Azure AD B2C. However, it only accepts unhashed passwords, which is completely useless for any modern system, which should ONLY be using hashed and salted passwords. What would actually make this feature useful is to include fields for hashed password, hash algorithm (any of several standard ones), salt and salt method (i.e., appended, prepended, etc).