Everything you wanted to know about Azure AD B2C custom policy samples but were afraid to ask!

Sample by franc11s from the Noun Project

There are a lot of custom policy samples scattered all over the Internet so I thought I would try and collate them in one place

Invariably, the links will change and break. Please report these in the comments. Also, please report any others that you think should be added.

I haven’t tried all of them so no guarantees and use them at your own risk.

Some are quite old so beware.

And inevitably there is duplication. Use your judgement 😃

Just do a search across this page.

Azure Active Directory B2C: Custom CIAM User Journeys

Look here.

Local account policy enhancements

Revoke Azure AD B2C session cookies — Demonstrates how to revoke the single sign on cookies after a refresh token has been revoked.

Password reset via Email or Phone verification — This demonstrates how to verify a user via Email or SMS on a single screen.

Sign In and Sign Up with Username or Email — This sample combines the UX of both the Email and Username based journeys.

Split Sign-up into separate steps for email verification and account creation — 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. The first step performs Email Verification only, avoiding all other default fields related to users' registration. The 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 are needed.

Provide consent UI to API scopes — 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 — 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.

Local account change sign-in name email address — 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.

Password-less sign-in with email verification — Password-less authentication is a type of authentication where the 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 users to sign-in, simply by providing and verifying the sign-in email address using an OTP code (one-time password).

Custom email verification — DisplayControls — This allows you to send your own custom email verification email during sign-up or password reset user journeys. The is a working example of the sample reference on the Microsoft B2C documentation site — here.

Custom SMS provider — DisplayControls Integrate a custom SMS provider in Azure Active Directory B2C (Azure AD B2C) to customized SMS’ to users that perform multi-factor authentication to your application. By using DisplayControls (currently in preview) and a third-party SMS provider, you can use your own contextualised SMS message, custom Phone Number, as well as support localization and custom one-time password (OTP) settings.

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.

Force password reset first logon — Demonstrates how to force a user to reset their password on the first logon.

Sign-up and sign-in with embedded password reset — This policy demonstrates how to 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 — Demonstrates how to force a user to reset their password after 90 days from the last time the user set their password.

Password reset only — This example policy prevents issuing an access token to the user after resetting their password.

Username discovery — This example shows how to discover a username by email address. It’s useful when a user forgot their username and remembers only their email address.

Azure AD B2C Invitation — This sample console app demonstrates how to send a sign-up email invitation. After you sent the invitation, the user clicks on the Confirm account link, which opens the sign-up page (without the need to validate the email again). Use this approach when you need to create the user's account beforehand while allowing the user to choose the password on the initial sign in. This approach is better than creating an account via Graph API and sending the password to the user via some communication means.

Email Verification at Sign In — For scenarios where you would like users to validate their email via TOTP on every sign in.

Google Captcha on Sign In — An example set of policies that integrates Google Captcha into the sign in journey.

Login with Phone Number — An example set of policies for password-less login via Phone Number (SMS or Phone Call).

Password Reset with Phone Number — An example policy to reset a user's password using a Phone Number (SMS or Phone Call).

Password reset without the ability to use the last password — For scenarios where you need to implement a password reset/change flow where the user cannot use their currently set password.

Disable and lockout an account after a period of inactivity — 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 user's login attempt in the case the user logs in after the time period.

Email delivered account redemption link — This sample demonstrates how to allow the user to sign up to a web application by providing their email which sends the user a magic link to complete their account creation to their email.

Sign-in with a magic link — This sample demonstrates how a user can sign in to your web application by sending them a sign-in link. A magic link can be used to pre-populate user information, or accelerate the user through the user journey.

Banned password list — For scenarios where you need to implement a sign up and password reset/change flow where the user cannot use a new password that is part of a banned password list. This sample does not use an API.

Impersonation Flow — For scenarios where you require one user to impersonate another user. This is common for the 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.

Sign-in with FIDO — Demonstrates how to sign-in with a FIDO authenticator (as a first-factor authentication). This policy uses the WebAuthn standard to register new credential and sign-in with FIDO credential.

Sign-in with Home Realm Discovery and Default IdP — Demonstrates how to implement a sign in journey, where the user is automatically directed to their federated identity provider based on their email domain. And users who arrive with an unknown domain are redirected to a default identity provider.

Terms of Service with Sign-in or Sign-up — Demonstrates how to implement Terms of Service within a SUSI experience. This policy writes a configurable policy version onto an attribute stored in the directory. If you update the version within the policy, it will prompt the user during the next login to force the user to accept the new terms of service agreement.

sign-up or sign-in policy with a link to sign-up page — 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.

sign-up or sign-in policy checks if client Id is allowed to call the policy — Checks if the application is allowed to call the b2c sign-in sign-up policy. Uses a claims resolver to get the client ID from the incoming OIDC request, and uses a claims transformation to see if the client id is on an allowed list of application ID’s. If the client Id is not on the allowed list, a customizable error message on a block page is shown to the user, blocking access to the policy.

Social account policy enhancements

Social identity provider force email verification — When a user signs in with a social account, in some scenarios, the identity provider doesn’t share the email address. This sample demonstrates how to force the user to provide and validate an email address.

Dynamic identity provider selection — Demonstrates how to dynamically filter the list of social identity providers rendered to the user based on the requests application ID. In the following screenshot, the user can select from the list of identity providers, such as Facebook, Google+, and Amazon. With Azure AD B2C custom policies, you can configure the technical profiles to be displayed based on a claim’s value. The claim value contains the list of identity providers to be rendered.

Home Realm Discovery page — Demonstrates how to create a home realm discovery page. On the sign-in page, the user provides their sign-in email address and clicks continue. B2C checks the domain portion of the sign-in email address. If the domain name is contoso.com the user is redirected to Contoso.com Azure AD to complete the sign-in. Otherwise, the user continues the sign-in with username and password. In both cases (AAD B2C local account and AAD account), the user does not need to retype the user name.

Sign-in with social identity provider and force email uniqueness — Demonstrates how to force a social account user to provide and validate their email address, and also checks that there is no other account with the same email address.

Account linkage — (new version, one policy for both link and unlink) — With Azure AD B2C an account can have multiple identities, local (username and password), or social/enterprise identity (such as Facebook or AAD). This Azure AD B2C sample demonstrates how to link and unlink existing Azure AD B2C account to a social identity. Unified policy for link and unlink.

Account linkage — (a policy for link and another policy for unlink.) — With Azure AD B2C an account can have multiple identities, local (username and password), or social/enterprise identity (such as Facebook or AAD). This Azure AD B2C sample demonstrates how to link and unlink existing Azure AD B2C account to a social identity.

Link a local account to federated account — Demonstrates how to link a user who logged in via a federated provider to a pre-created AAD B2C Local Account.

Preventing logon for Social or External IdP Accounts when Disabled in AAD B2C — For scenarios where you would like to prevent logons via Social or External IdPs when the account has been disabled in Azure AD B2C.

Sign in with Apple as a Custom OpenID Connect identity provider — Demonstrates how to gather the correct configuration information to setup Sign in with Apple as an OpenID Connect identity provider.

Sign in with REST API identity provider — Demonstrates how to allow users to sign-in with credentials stored in a legacy identity provider using REST API services.

Sign in through Azure AD as the identity provider, and include original Idp token — Demonstrates how to sign in through a federated identity provider, Azure AD, and include the original identity provider token (Azure AD Bearer Token) as part of the B2C issued token.

Multi factor authentication enhancements

Integrate Twilio Verify API for PSD2 SCA — The following sample guides you through integrating Azure AD B2C authentication with Twilio Verify API to enable your organization to meet PSD2 SCA requirements.

Edit MFA phone number — Demonstrates how to allow users 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.

TOTP multi-factor authentication — Custom MFA solution, based on TOTP code. Allowing users to sign-in with Microsoft or Google authenticator apps.

Sign In With Authenticator — This is a sample to show how you can create a B2C Custom Policy to signin with Authenticator Apps to B2C. It is related to the custom-mfa-totp sample, which shows how to use the Authenticator app as MFA.

Authy App multi-factor authentication — Custom MFA solution, based on Authy App (push notification). Allowing users to sign-in with Twilio Auth App (authenticator apps).

MFA with either Phone (Call/SMS) or Email verification — Allow the user to do MFA by either Phone (Call/SMS) or Email verification, with the ability to change this preference via Profile Edit.

Add & Select 2 MFA phone numbers at SignIn/Signup — 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 after timeout or IP change — A policy that forces the user to do MFA on 3 conditions:

1. The user has newly signed up.
2. The user has not done MFA in the last X seconds.
3. The user is logging in from a different IP than they last logged in from.

Unknown Devices MFA — Demonstrates how to detect unknown devices which might be required to prompt MFA as illustrated in this particular sample or send an email to the user signing in from an unknown device.

User interface enhancements

Render dynamic dropdown box — For scenarios where you would like to fetch information during the runtime of the authentication flow and display this data as a dropdown box dynamically for the user to make a selection. In this example, a user's identifier is sent to an API, which returns a set of emails for them to select. The selected email is returned in the token.

Generic enhancements

Delete my account — Demonstrates how to delete a local or social account from the directory

Integrating Azure AD B2C with TypingDNA — This sample demonstrates how to integrate TypingDNA as a PSD2 SCA compliant authentication factor. Find more about TypingDNA here.

Password Reset OTP only sent if Email is registered — Demonstrate how to use a displayControl to send One-Time-Passcodes to users only if the email is registered against a user in the directory.

Relying party app Role-Based Access Control (RBAC) — Enables fine-grained access management for your relying party applications. Using RBAC, you can grant only the amount of access that users need to perform their jobs in your application. This sample policy (along with the REST API service) demonstrates how to read user’s group membership, add the groups to the JWT token and also prevent users from sign-in if they aren’t members of one of the predefined security groups.

Sign-up with social and local account — Demonstrate how to create a policy that allows a user to sign-up with a social account linked to a local account

Integrate REST API claims exchanges and input validation — A sample .Net core web API, demonstrates the use of Restful technical profile in user journey’s orchestration step and as a validation technical profile.

Remote profile — Demonstrates how to store and read user profiles from a remote database.

Username based journey — For scenarios where you would like users to sign up and sign in with Usernames rather than Emails.

Custom claims provider — A custom OpenId connect claims provider that federates with Azure AD B2C over OIDC protocol.

Obtain the Microsoft Graph access token for an Azure AD Federated logon — For scenarios where we would like to obtain the Microsoft Graph API token for an Azure AD federated logon in the context of the logged-in user. For example, this could be used to read the user's Exchange Online mailbox within an Azure AD B2C application.

AAD Authentication with REST — Pass-through authentication to Azure AD (no user created in B2C), then calls a REST API to obtain more claims.

App migration

Angular5 — This guide shows how to migrate an existing Angular SPA application to be protected with Azure AD B2C authentication.

User migration

Just in time migration v1 — In this sample, Azure AD B2C calls a REST API that validates the credential, and migrates the account with a Graph API call.

Just in time migration v2 — In this sample, Azure AD B2C calls a REST API to validate the credentials, return the user profile to B2C from an Azure Table, and B2C creates the account in the directory.

Seamless-account-migration — Where accounts have been pre-migrated into Azure AD B2C and you want to update the password on the account on the initial sign in. Azure AD B2C calls a REST API to validate the credentials for accounts marked as requiring migration (via attribute) against a legacy identity provider, returns a successful response to Azure AD B2C, and Azure AD B2C writes the password to the account in the directory.

B2C to B2C Migration — Migrate users from one B2C instance to another using just-in-time migration.

Conditional Access

Sign-in with 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.

Web Test

SignIn Web test — This sample web test shows how to run tests and monitor results of B2C sign in’s, using Azure Application Insights.

CI/CD

Azure Devops — An example AzureDevOps pipeline that uploads policies regardless of naming convention.

Missing from CIAM menu

There are a number of policies in the repo. not referenced on the menu page.

Not sure why they are missing but I’m adding them for completeness.

Account linkage at signup

Here.

In Azure AD B2C you can have a Local Account of alicecontoso@gmail.com at the same time, if you federate with Google’s IDP, you can have another account authenticating as alicecontoso@gmail.com with Google. There is no correlation between the two accounts. You can view this two ways; either that the user chose to have it this way or that it happened by mistake and the user doesn’t want it this way.

The sample on account linkage (the unified one above) shows you how the user can correct the problem by joining the two accounts, but that is active action by the user. This sample shows you a different approach — avoiding that it happens in the first place.

Change password

Here.

Check host name

Here.

This sample provides an example of how to block access to a 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.

This is particularly useful when using custom domain(s) with Azure AD B2C tenant and you like to block policy access via default hostname *.b2login.com.

Custom email verification

Here.

This custom email verification solution allows you to send your own custom email verification during the sign-up or password reset user journey.

The solution requires using Azure AD B2C custom policy and a REST API endpoint that sends and verifies the email address.

Encrypted profile

Here.

This sample demonstrates a way to encrypt the attributes stored on a user object in Azure AD B2C, including the signInName.

Home realm discovery page

Here.

This sample custom policy demonstrates how to create a home realm discovery page. On the sign-in page, the user provides the sign-in email address and clicks continue. B2C checks the domain portion of the sign-in email address.

If the domain name is contoso.com the user is redirected to Contoso.com Azure AD to complete the sign-in. Otherwise, the user continues the sign-in with the user name and password.

In both cases (AAD B2C local account and AAD account), the user doesn't need to retype the user name.

Custom introspection endpoint

Here.

As Azure AD B2C utilises JWT based tokens as opposed to opaque tokens there is no requirement to implement an introspection endpoint.

However, if your application requires an introspection endpoint you can utilise the code based on the user_info example.

Signup with an email invitation

Here.

This sample demonstrates an email-based invite to signup to a B2C Local Account.

It uses a signed B2C JWT token as a magic link in the email.

Account lockout

Here.

This demonstrates how to lockout an account after six unsuccessful sign-in attempts.

MFA parameter

Here.

Demonstrates how to redirect the user to a particular web address, using OpenID connect protocol.

The redirection to the specified URI includes OpenID connect parameters, such as redirect_uri, response_type, response_mode, nonce and state. The web page you redirect the user to, can ignore those parameters.

Password reset with username SMS verify

Here.

A B2C IEF custom policy that allows Password Reset via Phone Number (OTP) after entering your Username.

Progressive profile

Here.

A user will not be prompted for e.g. “Loyalty number” during registration.

But they will be progressively prompted for it during sign-in.

Redirection sample

Here.

Demonstrates how to redirect the user to a particular web address, using the OpenID connect protocol.

The redirection to the specified URI includes OpenID connect parameters, such as redirect_uri, response_type, response_mode, nonce and state.

The web page you redirect the user to, can ignore those parameters.

Remote Profile with Geo-based Storage

Here.

This sample demonstrates storing the user profile either in a B2C directory or in different Azure Table Storage repositories based on the user geography setting.

Sign in with a custom MFA

Here.

Sign-in with a custom SMS.

Sign in with Kakao

Here.

This sample shows how to setup Kakao as an identity provider in Azure AD B2C.

Kakao is a South Korean Internet company that provides a diverse set of services.

Sign in migration

Here.

This shows how to migrate a CIAM solution from AWS Cognito to B2C.

This is an end-to-end sample for migrating the users from AWS Cognito to Azure AD B2C.

Its intended purpose is to give you a sample where you can go through all steps in a real migration scenario.

It includes scripts for setting up AWS Cognito UserPools, importing users, migrating the users from AWS to B2C, using Custom Policies for seamless migrating users’ passwords and MFA phone to B2C at next login.

Please note that there is no special reason to why AWS Cognito was chosen other then it suited the purposes to illustrate how you migrate from something to B2C.

Store three letters of the password

Here.

A call center uses Azure AD B2C to validate a customer phoning in.

To do this, the call center takes three characters from the password and asks the customer calling in to provide the three characters plus some other known facts as part of the authentication process.

With the Identity Experience Framework, which underlies Azure Active Directory B2C (Azure AD B2C) custom policy, you can integrate with a RESTful API in a user journey.

This sample .Net core web API, demonstrate how to extract the three characters of the password, by calling a Restful technical profile in a validation technical profile.

During sign-up or password reset, the policy calls a REST API to HASH three letters of the password and store the values in the user profile.

TOTP

Here.

At the time of writing, this is a limited preview.

To provide a higher assurance multi-factor option, we are enabling “time based one time passcode” using Authenticator as an MFA choice for B2C customers.

This option will allow customers to save on the telephony charges associated with every step-up and still provide higher security than ever before for their end users accessing critical applications.

End users can download the Microsoft Authenticator app or any other authenticator app of their liking that supports the TOTP protocol.

This is a limited preview feature and the tenants need to be allow listed in order to use this feature.

Until the feature is in public preview, we recommend that you only use this feature in your non-prod tenants.

User info endpoint

Here.

Azure AD B2C custom user info endpoint.

Scenarios

These are to be found in the “scenarios” directory of the custom policy starter pack.

Some of these refer to previews and the GA version is to be found in the CIAM samples above. Some are quite old so beware.

aadb2c-ief-rest-api-netfw

The Contoso.AADB2C solution file is a visual studio solution sample for implementing REST API to work with B2C using custom policies.

This solution file applies to the REST samples with no auth, basic auth, and cert-based auth.

aadb2c-ief-rest-api-netfw-secure-basic

The Contoso.AADB2C solution file is a visual studio solution sample for implementing REST API to work with B2C using custom policies.

This solution file applies to the REST samples with basic auth.

aadb2c-ief-rest-api-netfw-secure-cert

The Contoso.AADB2C solution file is a visual studio solution sample for implementing REST API to work with B2C using custom policies.

This solution file applies to the REST samples with cert-based auth.

aadb2c-ief-setup-adfs2016-app

Federation with ADFS 2016.

SAML.

aadb2c-ief-setup-amzn-app

Federation with Amazon.

OpenId Connect (OIDC).

aadb2c-ief-setup-goog-app

Federation with Google.

OIDC.

adb2c-ief-setup-li-app

Federation with LinkedIn.

OIDC.

aadb2c-ief-setup-msa-app

Federation with an MSA account.

aadb2c-ief-setup-twitter-app

Federation with Twitter.

OIDC.

aadb2c-ief-ui-customization

Adding Dynamic UI Customization to Azure AD B2C Custom policy workflows.

With custom policy, you can also customize the look and feel for your user, dynamically. B2C custom policy allows you to send through a parameter in a query string. That parameter passes on to your HTML endpoint and can dynamically change the page content.

For example, you can change the B2C sign-up or sign in background image, based on a parameter you pass from your web/mobile application.

aadb2c-user-migration

When you plan to migrate your identity provider to Azure AD B2C, you may also need to migrate the users account as well.

This code sample and Azure AD B2C policy demonstrate how to migrate existing user accounts, from any identity provider to Azure AD B2C.

This code sample is not meant to be prescriptive, but rather describes two of several different approaches. The developer is responsible for suitability and performance.

For the latest version, see here.

Keep me signed in

KMSI policy.

Linkedin-identity-provider

Password change

Phone-number-username

These files were from the using phone number as a username in Azure AD B2C private preview.

Source / ROPC

Resource owner password credentials custom policy sample.

In Azure Active Directory (Azure AD) B2C, the resource owner password credentials (ROPC) flow is an OAuth standard authentication flow.

In this flow, an application, also known as the relying party, exchanges valid credentials for tokens. The credentials include a user ID and password.

The tokens returned are an ID token, an access token, and a refresh token.

Read more here.

Source / Terms of use

Display “Terms of Use” consent agreement.

Chris Padgett’s samples

Look here.

Sign_up_sign_in

Sign-up for a local account using an e-mail address and a phone number. The end-user is prompted for verification of the e-mail address and the phone number.

Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn’t been verified, then the end-user is prompted for verification of the e-mail address. If the phone number hasn’t been verified, then the end-user is prompted for verification of the phone number.

Sign_up_with_hibp

Sign-up for a local account using an e-mail address. The e-mail address and password are checked against Have I Been Pwned (HIBP) for whether they have been disclosed through a data breach. The end user is prompted for verification of the e-mail address.

Sign_up_with_keen

Sign-up for a local account using an e-mail address. The end user is prompted for verification of the e-mail address. A registration event about the new user is published to Keen.

Sign_up_with_mailgun

Sign-up for a local account using an e-mail address. The end-user is prompted for verification of the e-mail address. An e-mail notification about the new user is sent through Mailgun.

Sign_up_with_mandrill

Sign-up for a local account using an e-mail address. The end user is prompted for verification of the e-mail address. An e-mail notification about the new user is sent through Mandrill.

Sign_up_with_sendgrid

Sign-up for a local account using an e-mail address. The end user is prompted for verification of the e-mail address. An e-mail notification about the new user is sent through SendGrid.

Sign_up_without_verification

Sign-up for a local account using an e-mail address and a phone number. The end user is not prompted for verification of the e-mail address or the phone number.

Sign_in_with_verification

Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn’t been verified, then the end user is prompted for verification of the e-mail address. If the phone number hasn’t been verified, then the end-user is prompted for verification of the phone number.

Email_sign_up_any_sign_in

Sign-up for a local account using an e-mail address. The end-user is prompted for verification of the e-mail address. A phone number can be linked to the local account using the phone_linking policy. Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn’t been verified, then the end-user is prompted for verification of the e-mail address. If the phone number hasn’t been verified, then the end user is prompted for verification of the phone number.

Phone_sign_up_any_sign_in

Sign-up for a local account using a phone number. The end-user is prompted for verification of the phone number. An e-mail address can be linked to the local account using the email_linking policy. Sign-in for a local account using an e-mail address or a phone number. If the e-mail address hasn’t been verified, then the end-user is prompted for verification of the e-mail address. If the phone number hasn’t been verified, then the end user is prompted for verification of the phone number.

Email_linking

Linking of an e-mail address to a local account that has been registered using a phone number. The end user is prompted for verification of the e-mail address.

Phone_linking

Linking of a phone number to a local account that has been registered using an e-mail address. The end user is prompted for verification of the phone number.

Yoel Horvitz’s samples

Look here.

Azure AD B2C load testing

This Azure AD B2C sample load testing solution simulates sign-in and sign-up with local account, process, and measures its response. Use the load test sample solution to perform and determine your web application and B2C policy behavior under anticipated peak load conditions. Using this load test helps you identify the maximum operating capacity of your tenant as well as any bottlenecks on your web app, and determine which element is causing degradation.

Spring Security SAML Extension for Azure AD B2C

This solution demonstrates how to integrate Java-based application with Azure AD B2C, using SAML protocol. The solution is based on the Spring Security SAML Extension project.

Jas Suri’s samples

Look here.

PowerShell to configure and upload or download a set of B2C IEF policies

PowerShell script with two functions:

1. Configure and upload policies

• Modifies the xml of a set of IEF policies replacing them with values from the target B2C tenant and an optional configuration (useful if policies need to be used in different tenants — Dev, QA, etc. — with different REST URLs, key names, etc.)
• Optionally uploads the files to B2C tenants

2. Download existing custom journeys from a tenant

B2C advanced policies

Look here.

AppSamples iOS TouchID

B2C with iOS app and Touch ID.

Azure Functions Samples

These can be uploaded into Azure Functions directly

• SendMail is a sample for sending welcome emails with content
• CalculatePlayerProfilePercentComplete -calculates completion of a profile based on attributes that have been filled by the end-user
• LookUpLoyalty and CheckPlayerTag are very simple API to complete the getting started with b2c custom policy and REST API samples

Account linking

This folder contains a complete starter pack to enable account linking. The key pieces are defined and identified below (e.g. user journey, technical profiles, and claims transformations)

Wingtip games B2C

Complete project for Wingtip games.

This website no longer works but there is a ton of good stuff in this repo.

Well worth your time to have a look through the code.

Azure AD B2C Community

Look here.

azureadb2ccommunity.io

Azure AD B2C Community Website.

There is a ton of good stuff here but most of it is not directly custom policy related.

Partner integrations

This repo contains samples which provide end to end integration between Azure AD and partner solutions.

• Dynamics Fraud Protection — Integrate Azure AD B2C with Dynamics Fraud Protection to externally fingerprint every sign in or sign up attempt and watch for any past or present suspicious behaviour.
• Experian — Integrate Azure AD B2C with Experian.
• IDology — Integrate Azure AD B2C with IDology.
• Jumio — Jumio enables real-time automated ID verification, safeguarding customer data. Here, we integrating Jumio ID verification service and Azure AD B2C with the help of an Intermediate REST API Service.
• Nevis — Nevis provides a mobile-first, fully-brandable and secure authentication experience for the end-users with Azure AD B2C. Enables strong customer authentication (SCA) and complies with PSD2 (Payment Services Directive 2) transaction requirements using the whitelabel NEVIS Access App
• OnFido — OnFido is a Document ID and facial biometrics verification SaaS that allows companies to meet “Know Your Customer” and Identity requirements in real-time. Here, we are integrating and hosting the OnFido document client within Azure AD B2C.
• ThreatMetrix — Integrate Azure AD B2C with ThreatMetrix.
• Twilio Verify API for PSD2 SCA — The following sample guides you through integrating Azure AD B2C authentication with Twilio Verify API to enable your organization to meet PSD2 SCA requirements.
• TypingDNA — This sample demonstrates how to integrate TypingDNA as a PSD2 SCA compliant authentication factor. Find more about TypingDNA here.

User-migration

When you plan to migrate your identity provider to Azure AD B2C, you may also need to migrate the user's account as well.

Saml SP

Azure AD B2C SAML Service Provider.

Both IDP and SP initiated.

Sign in with I-Frame

Rest API

Azure AD B2C integration with REST API services.

With the Identity Experience Framework, which underlies Azure Active Directory B2C (Azure AD B2C), you can integrate with a RESTful API in a user journey.

This sample .Net core web API, demonstrate the use of Restful technical profile in user journey’s orchestration step and as a validation technical profile.

Integration demo IPIfication

The repository contains code that demonstrates an integration between Azure AD B2C and IPification.

Woodgrove Groceries demo

Woodgrove Groceries Azure AD B2C Demo.

This repository includes all the relevant source code and policies for the demo site.

Well worth your time to have a look through the code.

Integration demo PASS

This repository contains code which demonstrates an integration between Azure AD B2C and PASS, a Korean mobile phone-based authentication service.

Hope this helps 😃

All good!