Quick Deploy Samples

This section will deploy a sample policy from the Azure AD B2C Samples GitHub to your Azure AD B2C directory. All supported samples for quick-deploy are listed in the table below.

If you believe you attempted to upload a sample which met these conditions, but did not upload successfully, raise an issue here.

.onmicrosoft.com

Possible sample values


Name Sample Folder Name Description
GDPR Age Gating age-gating Enables you to identify minors that want to use your application, with, or without parental consent. You can choose to block the minor from signing-in to the application.
Restrict B2C Policy to specific App Registration allow-list-applications Only permits certain application registrations to call certain B2C policy Id's.
Auto account linking auto-account-linking This policy sample demonstrates how to link an account when a user arrives with the same email as an existing account. When the email is detected as being the same, the user is prompted to sign in with one of the methods already registered on the existing account. Once complete, the account is linked.
Banned password list banned-password-list-no-API Banned password list prevention during Sign up and password reset/change flow. This sample does not use an API.
Local account change sign-in name email address change-sign-in-name During sign-in with a local account, a user may want to change the sign-in name (email address). This sample policy demonstrates how to allow a user to provide and validate a new email address, and store the new email address to the Azure Active Directory user account. After the user changes their email address, subsequent logins require the use of the new email address.
Allow/Deny based on Hostname check-host-name This sample provides an example of how to block access to particular B2C policy based on the [Hostname] of the request, e.g. allow requests made to the policy using login.contoso.com but block foo.b2clogin.com. Useful when using custom domain(s) with Azure AD B2C.
Sign-in with Conditional access conditional-access Azure Active Directory (Azure AD) Conditional Access is the tool used by Azure AD B2C to bring signals together, make decisions, and enforce organizational policies. Automating risk assessment with policy conditions means risky sign-ins are at once identified and remediated or blocked.
Delete my account delete-my-account Demonstrates how to delete a local or social account from the directory
Disable and lockout an account after a period of inactivity disable-inactive-account For scenarios where you need to prevent users logging into the application after a set number of days. The account will also be disabled at the time of the users login attempt in the case the user logs in after the time period.
Dynamic sign up or sign in dynamic-sign-up-sign-in allows dynamically detecting whether a user can sign in or sign up. The user enters their email and is asked to verify their password if the account exists. If the account does not exist, the user goes through a sign up flow.
Edit MFA phone number edit-mfa-phone-number Demonstrates how to allow user to provide and validate a new MFA phone number. After the user changes their MFA phone number, on the next login, the user needs to provide the new phone number instead of the old one.
Sign-up and sign-in with embedded password reset embedded-password-reset Embed the password reset flow a part of the sign-up or sign-in policy without the AADB2C90118 error message.
Force password after 90 days force-password-reset-after-90-days Force a user to reset their password after 90 days from the last time user set their password.
Force password reset first logon force-password-reset-first-logon Force a user to reset their password on the first logon.
Force password reset force-password-reset As an administrator, you can reset a user's password if the user forgets their password or you would like to force them to reset the password. In this policy sample, you'll learn how to force a password reset in these scenarios.
Impersonation Flow impersonation For scenarios where you require one user to impersonate another user. This is common for support desk or delegated administration of a user in an application or service. It is recommended to always issue the token of the original authenticated user and append additional information about the targeted impersonated user as part of the auth flow
MFA after timeout or IP change mfa-absolute-timeout-and-ip-change-trigger A policy which forces the user to do MFA on 3 conditions: The user has newly signed up, the user has not done MFA in the last X seconds, the user is logging in from a different IP than they last logged in from.
Add & Select 2 MFA phone numbers at SignIn/SignUp mfa-add-secondarymfa Demonstrates how to store two phone numbers in a secure manner in B2C and choose between any two at signIn. The flow prompts the user to store a secondary phone if only one phone number is one file. Once the two numbers are stored as part of SignUp or SignIn the user is given a choice to select between the two phones for their MFA on subsequent signIns.
MFA with either Phone (Call/SMS) or Email verification mfa-email-or-phone Allow the user to do MFA by either Phone (Call/SMS) or Email verification, with the ability to change this preference via Profile Edit.
Unknown Devices MFA - device fingerprinting mfa-unknown-devices Demonstrates how to detect unknown devices which might be required to prompt MFA as illustrated in this particular sample or send email to the user signing in from unknown device.
Password reset without the ability to use the last password password-reset-not-last-password Force password reset/change flow where the user cannot use their currently set password.
Password reset only password-reset-only Prevents issuing an access token to the user after resetting their password.
Password-less sign-in with email verification passwordless-email Password-less authentication is a type of authentication where user doesn't need to sign-in with their password. This is commonly used in B2C scenarios where users use your application infrequently and tend to forget their password. This sample policy demonstrates how to allow user to sign-in, simply by providing and verifying the sign-in email address using OTP code (one time password).
Password Reset sends verification code only if the email is registered pwd-reset-email-exists Display control to send verification code to users only if the email is registered against a user in the directory.
Password reset via email or phone verification pwd-reset-via-email-or-phone Verify a user via Email or SMS on a single screen.
Restore MFA phone number restore-mfa-phone-number Demonstrates how to allow user to change the phone in case it got lost. After the user changes their MFA phone number, on the next login, the user needs to provide the new phone number instead of the old one.
Revoke Azure AD B2C session cookies revoke-sso-sessions Demonstrates how to revoke the the single sign on cookies after a refresh token has been revoked.
Provide consent UI to API scopes service-consent For scenarios where you provide a plug and play service to other partners. When the user chooses to use your service through a partner application, the user must login with their account with your service, and consent to various scopes which allow your service to share information with the partner application.
Sign Up and Sign In with dynamic 'Terms of Use' prompt sign-in-sign-up-versioned-tou Demonstrates how to incorporate a TOU or T&Cs into your user journey with the ability for users to be prompted to re-consent when the TOU/T&Cs change.
sign-up or sign-in policy with a deep link to sign-up page sign-up-deep-link Adds a direct link to the sign-up page. A relying party application can include a query string parameter that takes the user directly to the sign-up page.
Allow sign up from specific email domains sign-up-domain-allowlist This policy demonstrates how to validate the email address domain name against a list of allowed domains.
Email second-factor signin-email-verification For scenarios where you would like users to validate their email via OTP on every sign in.
Login with Phone Number signup-signin-with-phone-number An example set of policies for password-less login via Phone Number (SMS or Phone Call).
Split Sign-up into separate steps for email verification and account creation split-email-verification-and-signup When you don't want to use the default Sign-up page which shows both email verification and user registration controls on the same page at once. This sample splits the default sign-up behavior into two separate steps. First step performs Email Verification only, avoiding all other default fields related to users registration. Second step (if email verification was successful) takes the users to a new screen where they can actually create their accounts. This uses Azure AD to send out emails, no separate email provider integrations needed.
Microsoft Authenticator TOTP totp Integrate native Microsoft Authenticator TOTP flow - [Enroll a user in TOTP with an authenticator app](https://docs.microsoft.com/azure/active-directory-b2c/multi-factor-authentication?pivots=b2c-user-flow#enroll-a-user-in-totp-with-an-authenticator-app-for-end-users)
UserInfo endpoint user-info-endpoint The UserInfo endpoint is part of the OpenID Connect standard (OIDC) specification and is designed to return claims about the authenticated user. The UserInfo endpoint is defined in the relying party policy using the EndPoint element.
Sign In and Sign Up with Username or Email username-or-email This sample combines the UX of both the Email and Username based journeys.
Username based journey username-signup-or-signin For scenarios where you would like users to sign up and sign in with Usernames rather than Emails.