I have been using the old way of resetting passwords in Azure B2C, namely when the user clicks the forgot password link on a Sign Up Sign In user flow (hereafter Susi), the B2C endpoint throws back to the app, and from this app we catch the error and redirect to a reset action in an account controller that essentially will point to a reset password flow.
Now it seems that from version 2.1.3 onward of the built-in Susi user flows we can opt for an option self-service password reset that as such does not throws back to the app but rather stays on the endpoint on the same susi flow.
However, this option is not set by default. Given that it simplifies the flow, I wonder why it is not set by default?
From a security and B2C perspective.
Before 2.1.3 version, password reset experience throws an error code AADB2C90118 , which is returned to application and application used to handle this error code reinitializing the authentication library to authenticate an Azure AD B2C password reset user flow, so if we provide this option by default there could be conflict with the existing self service password reset flow, in my view hence it is not turned on by default.
Related
In my custom policy I used the example here: https://github.com/azure-ad-b2c/samples/tree/master/policies/totp
I have TOTP working, but I want to make sure I will be able to reset it if a user doesn't have access to their authenticator app anymore.
NOTE: This is NOT using Azure B2C's built-in flows where you can enable TOTP in the settings.
This seems like an Admin controlled operation. In which case
List the softwareOathMethods for the user, here.
Delete the softwareOathMethod for the user, here.
The B2C policy will then ask the user to re-enrol an authenticator device on next sign-in.
My scenario is a public website, with authenticated access that is managed by AzureAdB2C, and the authentication is not embedded but on a subdomain style. In the authentication form I see that there's the option for password reset (for someone who forgets it) but my question is when the user is already authenticated and so outside Azure context, how can he ask for a password change?
Is there any endpoint or so (that would receive the email linked to the account)?
Thank you
Still not clear because you mention "fire the change/reset password flow?". Which is it or is it both?
If reset, you can use a custom policy. Just put the link to the policy on your page.
There are a number of password reset flows that may be of interest.
For change password, see here. Again, just put the policy link on the page.
Unsure if you would have to login again.
You can Configure password change using custom policies in Azure Active Directory B2C.
In Azure Active Directory B2C (Azure AD B2C), you can enable users who are signed in with a local account to change their password without having to prove their identity through email verification. The password change flow involves following steps:
The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step.
The user verifies the Old password, and then creates and confirms the New password.
If the question is to reset the password because the user forgot it but is still logged in, I can imagine logging out the user and redirecting them to the login page where they can choose the reset password option.
EDIT:
The Azure AD B2C article Set up self-service password reset for your customers states that
This article applies to self-service password reset used in the context of the standard Sign in user flow, which uses Local Account SignIn as the identity provider. If you need fully customizable password reset user flows invoked from your app, see this article.
Somehow resetting your password with a password reset flow / custom policy while you're logged in and don't 'need' your current password feels weird.
We have a Custom Policy that is based on the SocialAndLocalAccounts starter pack.
We have been adding support from Home Realm Discovery based on this sample HomeRealmDiscovery-Modern to redirect users using third-party-providers to their correct sign-in page (IdP)
We have also added support for Domain Hints to entirely skip our sign-in page for users that sign-in via a third-party identity provider.
The policy makes use of the new released Self-Served Password Reset as per official docs.
What's the issue?
When the user goes through the "Self-Served Password Reset", the B2C session is left in a corrupted state. If the user is redirected back to B2C, the session is not picked up.
How can we say that? What is the use case?
Steps to reproduce:
1: User goes to the application which redirects the user to the B2C Sign-In page.
2: User enters local account email (Gmail) and on the next Screen clicks on "Forgot your password" link which is implemented using the Self-Served Password Reset.
3: User goes correctly through the password reset flow, and ultimately enters the "MFA" factor (SMS code).
4: User correctly gets redirected to the Application with an ID token, successful login.
6: User clicks a link to a new/different application using the same custom policy.
7: The new application redirects the user to B2C (same custom policy)
Expected Result: The user should have a valid B2C Session and should not be prompted to sign-in again, but instead redirected to the callback of the new application with a valid id-token.
Actual Result: The user is sent back to the new application with an error message in the callback URL, and because of the error redirected back to B2C to re-login.
Error Message:
AADB2C90051: No suitable claims providers were found.
Correlation ID: c014004a-d2da-4000-83e5-6d648f9acccc
Timestamp: 2021-06-16 07:17:16Z
IMPORTANT: If the user goes through the normal sign-in flow (no password reset), everything works correctly. The user can switch between different applications and B2C picks-up the session correctly, without throwing errors or prompting a new sign-in. SSO among the different apps works as intended.
Here is the full TrustFrameworkExtention file which contains all the logic and extends from the Base file of the starter pack:
TrustFrameworkExtention.xml
Try this:
In CreateidentityProvidersCollectionLogic change SM-Noop to SM-DOMAIN.
In SM-DOMAIN add:
<PersistedClaim ClaimTypeReferenceId="identityProviders" />
I have a single claims provider in my Azure B2C custom policy - an SSO with our Azure Active Directory (AAD).
I can see that when there is only a single claims provider then B2C does not bother with presenting the B2C login page with only one button - rather it takes you directly to login with the only provider you have configured.
This presents me with the following problem because I, and many of my Company's users, am automatically logged in to the AAD. When I log out of the application that is secured by B2C the logic is to return to the B2C login page but instead it straight away logs me back in again.
What I would like is to log out and be presented with the login screen, rather than automatically being logged in again. I can change the app so that on logout you are actually redirected to a "you have been logged out" page, but this is not desirable.
How can I "force" the login page to show even though there's only one option available to the user?
In OpenID Connect you add prompt=login to force authentication when redirecting to the B2C Policy.
There is an equivalent parameter for SAML. I don't know if the built-in flows will propagate this, but if you are doing custom policy you certainly can go back to the federated identity provider and force authentication again.
See the prompt parameter here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#send-the-sign-in-request
I have an asp.net web application that authenticates via Azure AD B2C tenant. I have a sign-up-sign-in policy [login is using username instead of email] with MFA turned on. I have also setup Custom UI login page [unified.html] and MFA page [phonefactor.html] in a storage blob that the policy points to. I am able to authenticate the user via the custom login page and login with MFA. The issue is when I create a new user and force the user to change the password at their first login, instead of redirecting the user to the change password screen, I am getting an invalid username and password message. When I use the Sign-In policy instead of sign-up-sign-in, the redirection to change the password works for the new user. But the sign-in policy does not have the option to specify Custom UI for login page. Am I missing anything here and how can I make this work with the sign-up-sign-in policy.
Also is there any way to get the "Password" hint like the "Username" hint in the company branding ... Password hint is not available
forceChangePasswordNextLogin only works on the sign-in policy which does not support UI customization.
In order to achieve similar functionality in the unified sign-up/sign-in policy, you'll need to implement this functionality yourself.
One option to achieve similar (albeit not quite the same) functionality is by leveraging the Password Reset policy. You would be creating new users up-front and ensuring you configure their email. You then direct them straight to the Password Reset policy for their account activation. They'll receive an email with a code which once provided, will let them provide set their password.
There's already two outstanding feature asks in the Azure AD B2C Feedback Forum that you can support:
Support Force Password Reset
Fully Customizable Sign-In Page
UPDATE
For the DIY approach:
Create the users by setting up an Azure AD app for your back-end API as outlined here:
https://learn.microsoft.com/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
Have your back-end API call the Graph API like this app does to create the users: https://github.com/AzureADQuickStarts/B2C-GraphAPI-DotNet.git
Send the users directly to the reset password URL /authorize/ url..