Force Azure AD B2C sign-up for WordPress users

Introduction

Azure Active Directory B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs. See https://docs.microsoft.com/en-us/azure/active-directory-b2c/overview for details. Use this guide, if you want to force your website users to register themselves in Azure AD B2C before they register in WordPress and rely on WPO365 to create a new WordPress user account when the user returns to your website. 

What you can expect

When you configure WPO365 to enable users to sign in with Azure AD B2C, then you also need a solution to create new users in Azure AD B2C. The benefits of this approach include:

• Azure AD B2C is a very strong and highly configurable solution for managing your (website) identities including support for multifactor authentication, password strength, custom branding, configuring a custom login domain, embedding the login experience into your WordPress website, out-of-the-box user flows for sign-up and password reset, custom user attributes and many other features.
• Users sign in with Microsoft and do not know their WordPress password. Instead, the WordPress password is configured by WPO365 and this will help protect you against weak passwords.
• Because users sign in with Microsoft and then return to your WordPress website where WPO365 will handle registration of new users, you do not need to allow anyone to register.
• Optionally you can configure WPO365 to automatically redirect anyone who tries to access your site's login page to the Microsoft login page instead and doing so will help protect you against brute-force attacks.

If your WordPress website offers features that require users to register - for example when you sell products or online-courses - then WPO365's solution for Azure AD B2C can help you achieve the following user flow.

• On your checkout page, WPO365 can render - for example - two buttons for users when he / she is not yet logged in (using - for example - the Block Visibility plugin). One button for existing users to log in (with Microsoft) and another button for first-time users to sign-up (as a website user in your Azure AD B2C tenant). If the user clicks the sign-up button, he / she will be send to the endpoint of your Azure AD B2C's sign-up user flow.
• The user interacts with your (optionally customized) Azure AD B2C sign-up form and creates an account in Azure AD B2C. As soon as he / she has completed the sign-up and created a new account in Azure AD B2C, he / she is returned to your website.
• When the user returns from Azure AD B2C, WPO365 will detect the returning user and the ID token that Azure AD B2C sends along. It will process the ID token and the (custom) claims it contains to create a new WordPress user, whereby WPO365 offers many options to configure how the user is created e.g. password length, custom claim for the user name, mapping of other claims e.g. for given name, surname and display name.
• WPO365 will also remember that the user was initially checking out of your website and it will return the now logged-in WordPress user to your website's checkout page. Now the user can complete the transaction e.g. by paying for the goods and receiving further instructions.
• The next time the user returns to the website and needs access to his account e.g. to manage licenses, subscriptions or get access to content, you can add the specific URL e.g. https://www.contoso.com/your-account/ to WPO365's list of Private pages. Adding a URL to this list, will send any user that is currently not logged in, to your Azure AD B2C's sign-in endpoint. Now the user can sign in - for example using his / her email address. Once the user authenticated successfully with your Azure AD B2C tenant, he / she is send back to your website. Here WPO365 will again detect the returning user and the ID token that Azure AD B2C sends along. It will process the ID token and signs in the existing WordPress user, who has now access to his personal account management pages and restricted content.
• Last but not least, you want to avoid the user to attempt to try and sign into WordPress using his / her local WordPress account. To avoid any confusion, you therefore would like to force the user to always sign in using Azure AD B2C. With WPO365 this can achieved by enabling Azure AD B2C based Single Sign-on for the default (or custom) login page. If enabled, users that navigate to the site's login page, will always be redirected to the Azure AD B2C login page instead. Administrators, however, can (and should) store a secret that - if added to the site's login page URL - allows them to bypass the auto-redirection. This way, administrators can still sign into the site using a local WordPress (administrator) account when needed.

Before you start

• You have reviewed the installation prerequisites and have installed and activated the WPO365 | LOGIN plugin (see Getting started - Installation).
• You have configured Azure AD B2C based Single Sign-on (see Azure AD B2C based Single Sign-on).
• In order to support the advanced Azure AD B2C scenarios in this article, you must have at least purchased the WPO365 | LOGIN+ extension or any of the bundles ( WPO366 | SYNC or WPO365 | INTRANET).
• You are a Global Administrator for your company’s Microsoft 365 tenant / Azure AD B2C directory (or you have at least obtained approval for your plans from your company's Global Administrator ).
• You are an Administrator for your WordPress website.
• Your website uses SSL and the internet address starts with https://.

Azure AD B2C

The steps to configure Azure AD B2C are basically beyond the scope of the WPO365 documentation. The following steps, however, are presented as a reference implementation. Some remarks are added that outline important steps that you should use to verify your own Azure B2C configuration.

• Create an Azure AD B2C tenant (see https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-tenant).
• Register your WordPress website in Azure AD B2C by creating an App registration (see https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-register-applications). Please ensure that you completed the following steps
  • Register a Web application and as Redirect URI you must enter your website's URI with a trailing "/" if you configured WordPress permalinks e.g. https://www.wpo365.com/.
  • Create a client secret and make sure to copy the secret's Value and not the secret's ID and save if temporarily in a text editor (you cannot retrieve it once you navigate away from the page).
• Please note that you do not need to complete the last step to Enable ID token implicit grant.
• Create at least user flows to sign-in and sign-up (see https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-user-flow).
• And ensure that you either disabled the password reset option or otherwise add a password reset policy (recommended, see https://docs.microsoft.com/en-us/azure/active-directory-b2c/add-password-reset-policy?pivots=b2c-user-flow).

Plugin configuration

The previous scenario, whereby the user is sent to Azure AD B2C to sign-up doesn't require a lot of configuration on the side of WPO365 (assuming that you already configure Azure AD B2C based Single Sign-on). The only option that you must check, is Allow multiple B2C policies as shown below. This is needed, because you need to send existing users to a different endpoint as first-time users (see next paragraph for details).

Website check-out

Let's configure the website's checkout page. As already mentioned before, the checkout page should be modified so that it dynamically shows different content for logged-in users. As long as a user did not log into the website, you want to provide him / her with the choice to either sign-up (for first-time users) or to log in (for existing users). One solution to achieve this, is provided by the Block Visibility plugin. What follows below is an example of how (part of) the checkout page may look like, for a first-time user that did not yet signed up with the website.

The user can choose from two options to sign up or to log in. In edit-mode this looks as follows.

The first block is the Columns block and it has a custom configuration for Visibility and is configured to be visible to users that are logged-out (but not to users that are already logged-in). The Columns block is configured to show two columns and in each column, a Custom HTML block has been added. Here the necessary HTML for a custom simplistic WPO365 login has been added (see Add "Sign in with Microsoft" button to a WordPress login form). The difference between the two buttons is that the sign-up button has an additional parameter that specifies the Azure AD B2C policy / user flow for sign-up. Please note that in your case this policy may have a different name. Also note the 2nd parameter, that will ensure that the user is redirected back to the current page, after he / she returns to the website from your Azure AD B2C sign-up endpoint.

<div id="wpo365OpenIdRedirect" style="text-align: center">
	<button onclick="window.wpo365.pintraRedirect.toMsOnline('', location.href, '', 'B2C_1_sign_up_1')">
		Sign up
	</button>
</div>

The second block on the page, immediately below the columns, is the shopping cart and this is also visible for logged-out users (but not for logged-in users, who should see the checkout form instead) This example uses the digital ecommerce plugin from Easy Digital Downloads (EDD). Likely, you are using  a different plugin for your digital business e.g. LearnDash or WooCommerce. But the principles presented in this article will still be the same and apply.

The third block on the page is the checkout form and with the help of the Block Visibility plugin this block is only visible for logged-in users.

When a first-time user clicked the Sign-up button, he / she will be taken to your Azure AD B2C's sign-up endpoint. This experience can be greatly customized. You can - for example - upload a background image and logo and also customize the fields (see below) that the user should fill out.

Force Azure AD B2C login

You want to avoid the user to attempt to try and sign into WordPress using his / her local WordPress account. To avoid any confusion, you therefore would like to force the user to always sign in using Azure AD B2C. With WPO365 this can achieved by enabling Azure AD B2C based Single Sign-on for the default (or custom) login page. If enabled, users that navigate to the site's login page, will always be automatically redirected to the Azure AD B2C login page instead. 

Administrators, however, can (and should) store a secret that - if added to the site's login page URL - allows them to bypass the auto-redirection. This way, administrators can still sign into the site using a local WordPress (administrator) account when needed.

Obtaining (custom) user attributes

Let's say that the website requires additional information and each user that registers must also enter his / her VAT number. To achieve this, you must first define this attribute as a user attribute in your Azure AD B2C tenant as follows.

But that is not enough. You must now go to the separate user flows and ensure that the user is asked to enter this information when he / she signs up for the first time.

Plus you must enable this user attribute to be included (as an application claim) in the ID token that is sent to the website when the user successfully signed in.

Finally, WPO365's configuration must be updated and a mapping for the custom claim to WordPress user meta must be created. This will ensure that WPO365 will inspect each incoming ID token for the custom claim and if it is present, the information will be stored in a WordPress user meta field so that the information can be further processed by your website. The challenge is to find out the name of the custom claim. Luckily, WPO365 let's you inspect an ID token when you run the Plugin's self-test.

To view the ID token content, first locate the Can decoded the ID token test case. You will notice a View link and when you click that link, the parsed ID token will be shown. In this case, a custom claim extension_VATNumber is sent and this contains the information that we are looking for. Now that we now the custom claim's name, we can update WPO365's Custom user fields mapping table as follows.

With this configuration in place, WPO365 will look for a custom claim with the name extension_VATNumber in the ID token (which has been selected as the source for custom user fields), saves the information in this claim in the usermeta table in WordPress for the current user using the key customerVatNumber. If you would check the option to Show Azure AD user attributes in a WordPress user profile then this information also be shown on a user's WordPress profile and the title for this field will be Customer VAT.