Define "ESTS" or change to a well-known term

[jackalvrus]

Many of the policy files use the term "ESTS" in comments. However, I can find no definition for this term in the starter pack or in any B2C documentation. One example of such comments:

        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). 
          This can only happen when authentication happened using a social IDP. If local account was created or authentication done
          using ESTS in step 2, then an user account must exist in the directory by this time. -->

[KevinCathcart]

Yeah, that abbreviation really should not have made it into the starter packs. Since I'm not a Microsoft employee, I cannot fix it, but what I can do is explain what it means.

ESTS is an abbreviation for EvoSTS. Now you know. See you next tim.... What? That is not really any better? Yeah, you probably want to know what that is too.

EvoSTS is the part of login.microsoft.com that is not deprecated for AAD B2C. Specifically the parts of login.microsoft.com that don't deal with user flows or custom policies. This is the underlying functionality shared with regular Azure Active Directory. The local account flows authenticate against EvoSTS.

It would probably help here to remember that AAD B2C consists of two parts. The first part is a mostly normal AAD tenant. The second part is the Identity Experience Framework (IEF). IEF is the part that runs user flows, and implements pretty much all of the B2C specific functionality. It uses the underlying AAD tenant to to store policies, as a user directory, as a source of app registration information, as a backend for handling phone based 2-factor auth, and to run conditional access evaluations.

The underlying AAD tenant is mostly fully functional, and is used used to authenticate for azure portal admin access. Authenticating directly against the underlying AAD tenant is possible in many cases, but will result in a different JWT, and does not utilize the user flows. Therefore it is not encouraged. However it does function in at least some scenarios. Indeed a lot of functionality that is blocked in azure portal UI still functions, but simply will not act as expected when using user flows, which is why they are blocked (to prevent confusion). I'm guessing there is probably some functionality that is actually blocked, l but I'm not sure the details.

Several other references to EvoSTS in the built in policies were changed to say login.microsoft.com in when creating the starter pack policies, or where simply omited completely if it made sense. That should have happened with ESTS too, but apparently that got overlooked.

[sparksterz]

Thanks @KevinCathcart - Also had no idea what that meant.