Hi folks, the Azure AD B2C team has been hard at work responding to feedback and adding capabilities to Azure AD B2C. Readers who visited us at the //build/ conference last month saw a few of these, but today the team is ready to share much more of their recent progress, including some great work on customization, management, and more social support. To walk us through the details we’re joined by Swaroop Krishnamurthy, a Program Manager from the Azure AD B2C Team.
As always, we welcome your feedback.
Director of Program Management
Microsoft Identity Developer Platform
I am Swaroop Krishnamurthy, a Program Manager at Microsoft on the Identity Developer Platform team. Today I am excited to announce a set of new features that we have recently added to Azure AD B2C, currently in preview. If you are new to Azure AD B2C, check out my intro talk from //build/.
The new features are:
- Support for Microsoft Account as a social identity provider. Already supported were Facebook, Google, LinkedIn and Amazon.
- Unified sign-up or sign-in policy.
- Self-service password reset policy.
- Configurable token lifetimes, session & single sign-on behavior.
- Easy access to B2C features on the Azure portal.
For an overview on each feature and links to documentation & samples, read on.
Microsoft Account support
Users with Microsoft Accounts can now sign-up and sign-in to your applications. Read this article to learn more on how to configure Microsoft Account in your B2C tenant.
If you select Microsoft Account in a sign-up or sign-in policy and run it (using the “Run now” option on the Azure portal), you will see the Microsoft Account button on the first page of the sign-up or sign-in experience.
Unified sign-up or sign-in policy
Typically, an application provides two separate buttons for sign-up and sign-in that users have to pick from. With the unified sign-up or sign-in policy, your application can provide a single experience for sign-up or sign-in based on context. Let’s look at this policy in action. Here is a demo web app (Proseware) with this single button:
When new and existing users click on a button called “Join / Sign in” they are given the choice to:
- Sign in using Google, Facebook or Microsoft Account.
- Sign in with an existing Proseware account (a local account).
- Create a new Proseware account.
The choice between signing into a Proseware account or creating a new one is straightforward. Let’s explore the social account use case instead. A new user, Jane, clicks on the “Sign in with Facebook” button. She is redirected to Facebook, where she signs in with her Facebook credentials and consents to releasing her information to Proseware.
The Azure AD B2C service recognizes that Jane is a new user (she didn’t have to explicitly sign-up with Facebook) and is asked to fill in her account details as required by Proseware. A user object is created for Jane in the B2C tenant.
The next time Jane signs into the Proseware application using Facebook, she is signed into the application directly (without having to consent or to enter account details again). All of this logic resides in the unified sign-up or sign-in policy and is orchestrated by Azure AD B2C’s Identity Experience Engine. The developer doesn’t need to code any of this. In addition, the UI on every page of this experience is fully customizable.
Click here for instructions on how to setup unified sign-up or sign-in policies in your B2C tenant.
We have also added two new code samples to demo this policy:
- A B2C .NET MVC web app that uses a unified sign-up or sign-in policy and a self-service password reset policy (see next section).
- A B2C Xamarin Forms app that uses a unified sign-up or sign-in policy and MSAL.NET, the new Microsoft Authentication Library, to obtain tokens & access a protected Web API.
Self-service password reset policy
So far, all applications in your B2C tenant had to share the same password reset experience . With this feature, you can create and use multiple, fully customizable password reset experiences. You can trigger the right password experience from your app using the corresponding policy name in an authentication request to Azure AD B2C. Let’s look at an example.
A user, Joe, has forgotten the password to his Proseware account. Joe provides his email address (email@example.com) on the password reset page (we will add other password recovery methods in the future).
By verifying the code sent to his email address, Joe can reset his password successfully.
Click here for instructions on how to setup self-service password reset policies in your B2C tenant.
Configurable token lifetimes, session & single sign-on behavior
Many of you have asked us for more control over the lifetimes of tokens issued by Azure AD B2C and on how sessions & single sign-on are handled across applications and policies. You can now configure these settings by editing your existing policies. Read this article on how to do this. A few use cases this feature enables are:
- Allow a user to stay signed into a mobile application indefinitely, as long as he or she is continually active on it.
- You can meet your security & compliance requirements by setting the right token lifetimes.
- You can disable SSO between two applications using the same sign-in policy.
- Force re-authentication when a user accesses a high-security part of your application.
Easy access to B2C features on the Azure portal
To improve discoverability of B2C Admin features, we have added a shortcut on the Azure portal. Sign into the Azure portal as the Global Administrator of your B2C tenant. If you are already signed in to a different tenant, switch tenants (on the top-right corner). Click “Browse” on the left hand navigation, and then on “Azure AD B2C” to access the B2C settings blade.
That’s it for now! We would love to hear your feedback! I’ll back soon with more things Azure AD B2C.
Swaroop Krishnamurthy (Twitter: @swaroop_kmurthy)
Senior Program Manager
Microsoft Identity Division