Hello and welcome to this month’s technical blog from WhoIAM. In this post, we will dig into how you might be able to implement password history in Azure AD B2C to make sure your customers aren’t reusing previous passwords when resetting an expired or forgotten password. Apart from being one of the most requested features in Azure AD B2C, support for maintaining password history is also a requirement to be in compliance with FDA regulations (Part 11, Electronic Records; Electronic Signatures – Scope and Application | FDA) as well as a variety of other industry regulations and best practices. As of when this blog’s being written, Azure AD B2C does support preventing a user from changing a password to the current password but doesn’t have native support for preventing the reuse of previous passwords.

To solve for password history in Azure AD B2C, we depend entirely on other Azure products to ensure scalability and security as well as manageability of the password history solution out of the same subscription to which your Azure AD B2C tenant is tied. Specifically, this implementation uses three Azure components:

1) Azure AD B2C Identity Experience Framework: Azure AD B2C custom policies are updated/modified to work with downstream components to ensure password history is inspected before allowing a user to update a password.

2) Azure App Service: An API service is hosted in an Azure App Service instance managed by your own corporate IT department. Two API endpoints are used – a Register PW endpoint and a Change PW endpoint. These APIs interface Azure AD B2C with Azure Key Vault to ensure previous passwords are stored and updated as needed.

3) Azure Key Vault: Previously used passwords that are hashed and salted are stored in an Azure Key Vault instance managed by your IT department.

Following is an architecture diagram for how you might go about orchestrating this flow:

Password history architecture diagram

Finally, you may also need to handle a few additional corner-cases such as making the number of stored passwords customizable, as well as preventing users from quickly cycling through a few new passwords, and reverting to their original favorite password. You may also want to extend your implementation by capturing current passwords into Azure Key Vault’s history when this solution is first introduced into your environment.

If you have other ideas or thoughts on how else you’ve solved for password history in Azure AD B2C, or just want to chat about how you might implement something like this in your own environment, please drop us a note from the contact form below, we’d love to hear from you.

The WhoIAM Team