0
votes

For a certain scenario we would like to force the user in the user journey during login to change his password. Reason: the password policy has changed, and her password doesn't comply with our latest policies. This validation is made by a ValidationTechnicalProfile. (the real reason is a bit more complex, but I think the details are not relevant)

The best flow from my point of view would be:

  1. User tries to login, password is correct but is not complex enough
  2. An extra page is shown, the user assigns the new password here
  3. User get's logged in as usual

I was thinking about setting "password expired" flag for the user, but this doesn't seem to be supported: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/16861051-aadb2c-force-password-reset

I didn't find a nice solution to do this, which wouldn't be misusing the provided customization features of AD B2C and provides good UX. The user optimally shouldn't have to re-enter his password or go to other sites via links or open his emails.

Another requirement is that we need custom HTML for all our B2C pages.

Do you have any recommendation how to achieve this?

I could imagine such solutions, but I'm not sure about these:

  • Showing error message, that he has to change his password and either showing link where he can do this or sending password change link via email. This is bad UX cause the user has to jump off the page, and if link is sent via email if he doesn't own the email address anymore he is also locked out.
  • Adding extra fields on some of the AD B2C Pages (e.g. Sign in) for setting new password. I'm not sure if it's a good idea.
  • Intagrating AD B2C password change or password reset page in the user journey. Is this possible?
1

1 Answers

0
votes

I recommended you integrate the password change step into the sign-in flow.

This is the best experience for the end user.

If the validation technical profile can output a claim that indicates whether the current password satisfies the password policy or not, then you can create another orchestration step, with this claim as a precondition for it, that handles the password change.