This sample solution demonstrates how to use custom email verification. The custom email verification solution allows you to send your own custom email verification during sign-up or password reset user journey. The solution required using Azure AD B2C custom policy and a REST API endpoint that sends the email verification and validates the verification code.
The key concept of custom email verification: During sign-up or password reset and change email custom policies, a user provides the sign-in email address. User clicks on continue, Azure AD B2C calls a REST API endpoint that generates a verification code. The verification code is sent to the user's email and return back to Azure AD B2C. On the next page (sign-up, password reset and change email) user is requested to provide the verification code (sent by email) along with the rest of the information, such as sign-up user profile, password reset the new password. When users click on the continue button, Azure AD B2C makes another call to the REST API, sending both the verification code generated in the previous step and the verification code provided by the end user. The REST API compares the verifications codes and lets the user update, or create the account
Custom email verification code deals with following scenarios:
- LocalAccountSignUpWithLogonEmail-FirstStep self-asserted technical profile
- Disables the default Azure AD B2C email verification, using the EnforceEmailVerification metadata
- Collects the email address
- Copies the email address to the CopyEmailAsReadOnly claim type
- Calls the REST-API-SendVerificationEmail validation technical profile that generates the verification code, sends the email
- Returns the verification code as output claim
- On the next orchestration step, B2C calls the LocalAccountSignUpWithLogonEmail-SecondPage technical profile. This Self asserted sign-up page. It's based on the LocalAccountSignUpWithLogonEmail, while removing the email claim and changing the validation technical profiles
- Presents the email in read only mode
- Asks the user to provide the verification code (sent by email), the passwords, and user profile
- When user clicks on continue, B2C runs the REST-API-verifyCode validation technical profile that compares the verification code provided by the user and the one generated by the REST API in the previous step.
- The second validation technical profile AAD-UserWriteUsingLogonEmail creates the account
- LocalAccountDiscoveryUsingEmailAddress self-asserted technical profile
- Disables the default Azure AD B2C email verification, using the EnforceEmailVerification metadata
- Collects the email address
- Calls the REST-API-SendVerificationEmail validation technical profile that generates the verification code, and sends the email
- Returns the verification code as output claim
- On the next orchestration step B2C calls the LocalAccountWritePasswordUsingObjectId-SecondStep technical profile. This Self asserted password reset page. It's based on the LocalAccountWritePasswordUsingObjectId, while adding the verification code functionality
- Asks the user to provide the verification code (sent by email) and the new password
- When user clicks on continue, B2C runs the REST-API-verifyCode validation technical profile that compares the verification code provided by the user and the one generated by the REST API in the previous step.
- The second validation technical profile AAD-UserWriteUsingLogonEmail creates the account
- Ask the user to sign-in with the local account email address
- Read the user profile from Azure AD
- LocalAccountEmailVerification-FirstStep self-asserted technical profile
- Disables the default Azure AD B2C email verification, using the EnforceEmailVerification metadata
- Collects the email address
- Calls the REST-API-SendVerificationEmail validation technical profile that generates the verification code, and sends the email
- Returns the verification code as output claim
- On the next orchestration step B2C calls the SelfAsserted-EmailVerification self-asserted technical profile
- Asks the user to provide the verification code (sent by email)
- When user clicks on continue, B2C runs the REST-API-verifyCode validation technical profile that compares the verification code provided by the user and the one generated by the REST API in the previous step.
- The second validation technical profile AAD-UserWriteEmailUsingObjectId store the new email address to the account
To run the visual studio solution, you need:
- Deploy this web app to Azure App Services. For more information, see Create and publish the web app
- Set the application settings. You can set the app settings directly from
appsettings.jsonn
file. Or use the better solution, from Azure portal. For more information, see: Configure web apps in Azure App Service
Secure the communication between Azure AD B2C to your Rest API. For more information, see: Secure your RESTful service by using client certificates OR Secure your RESTful services by using HTTP basic authentication
This sample policy is based on LocalAccounts starter pack.
- All changes are marked with Demo: comment inside the policy XML files.
- Make the necessary changes in the Action required comments
- IdentityController The custom policy calls this REST API
- appsettings.json application settings
- Models folder - this folder contains the necessary object-mapping classes
To test the sample solution, open the AADB2C.Invite.sln
Visual Studio solution in Visual Studio. In the AADB2C.Invite
project, open the appsettings.json
. Replace the app settings with your own values:
- SMTPServer: Your SMTP server
- SMTPPort: Your SMTP server port number
- SMTPUsername: SMTP user name, if necessary
- SMTPPassword: SMTP password, if necessary
- SMTPUseSSL: SMTP use SSL, true of false
- SMTPFromAddress: Send from email address
For example:
"AppSettings": {
"SMTPServer": "smtp.sendgrid.net",
"SMTPPort": 587,
"SMTPUsername": "[email protected]",
"SMTPPassword": "1234",
"SMTPUseSSL": true,
"SMTPFromAddress": "[email protected]"
}
If your policy is username based, make the nassacery changes:
- Sing-Up - Make your store the email address to the strongAuthenticationEmailAddress instead of the signInNames.emailAddress
- Password reset - After the validation, you should look up the account using the username (instead of the email address), and compare the return strongAuthenticationEmailAddress to the one provided and validated by the user.
- Chage email address - When you read and write, use the strongAuthenticationEmailAddress instead of the signInNames.emailAddress
The sample is developed and managed by the open-source community in GitHub. The application is not part of Azure AD B2C product and it's not supported under any Microsoft standard support program or service. The sample (Azure AD B2C policy and any companion code) is provided AS IS without warranty of any kind.
Note: This sample policy is based on logon with username policy. All changes are marked with Demo: comment inside the policy XML files. Make the nessacery changes in the Demo action required sections.