Typically you’ll have a RelyingParty (RP) custom policy that inherits from an extension policy that inherits from a base policy.

This is the way the starter pack is built.


Normally, you would login with an email address but you can also login with a username which is essentially any string of characters e.g. “123456”.

In built in policies, you can configure this on the identity provider but note that this is tenant wide.


This endpoint is part of the OAuth2 specification.

The base article is here.

Following the article, I created a Web application as follows:


This is based on this sample.

Note: there are other phone samples in the samples pack.

This sample shows how to sign up and sign in with a phone.

When you SUSI, you select the country from a drop-down list of country codes and then enter the phone number. An OTP is then sent to the phone that you have to enter to confirm that you own the phone.

This is fine in normal use but I have come across two problems in certain scenarios:

  • The county codes in the custom policy are restricted e.g. to the APAC region and…


The official docs are here.

I based this on the “Sign-up and sign-in with embedded password reset” policy simply because this already had a sub journey within the custom policy.

(BTW. This policy demonstrates how to embed the password reset flow in a part of the sign-up or sign-in policy without the AADB2C90118 error message). Very neat!

“A sub journey is a grouping of orchestration steps that can be invoked at any point within a user journey. You can use sub journeys to create reusable step sequences or implement branching to better represent the business logic”.

i.e. they are a…


Once you have created a B2C tenant, the next step is to run through all the steps in the “Getting Started” doc.

There is now a utility to do this for you!

The utility can be found here.


In B2C, federation (i.e. with Azure AD) is regarded as a social (e.g. Twitter) connection in terms of the custom policies.

By default, when you go though the user flow authentication with federation for the first time, you will be presented with this screen after entering your credentials.


I’ve answered hundreds of questions around Active Directory Federation Services (ADFS) claims rules in the old MDSN forum and this MSDN forum and in my previous blog and on stackoverflow so I thought I would consolidate some of the rules here.

I “saved” some of the old TechNet articles here so have a read there first. Note there are some good examples of regex there.

Many thanks to all the other contributors (too many to mention) whose wisdom is reflected here 😃

There’s no particular order to these.

This is a work-in-progress as I will keep adding to this as…


I’ve done a few of these and thought that I would note some of the gotchas I experienced.

There’s a good article here that takes you through the basics and it includes a complete SAML sample on Github that you can use as a reference.

The notes refer to the above sample.

PolicyId

The first thing to note is the PolicyId of your RP.

PolicyId="B2C_1A_SAML2_SU_SI"

(SU_SI = signup_signin).

This is used in a number of places.

In the SAML claims provider:

<Metadata> <!-- Action required: make sure value is the same one as configured in the relaying party application--> <Item Key="IssuerUri">https://tenant.b2clogin.com/tenant.onmicrosoft.com/B2C_1A_SAML2_SU_SI</Item>…

Rory Braybrook

NZ Microsoft Identity dude and MVP. Azure AD/B2C/ADFS/Auth0/identityserver. StackOverflow: https://bit.ly/2XU4yvJ Presentations: http://bit.ly/334ZPt5

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store