Question 269162 in Azure Question posted in
The official documentation to get you started can be found here.

Azure ADB2C : Disable e-mail verification, conditionally

We are using Azure B2C for authentication of our online application.
We now have a very specific case, where a customer is willing to sign in with un-existing e-mail addresses. (so basically using them as user name / pwd).

While this is something we hoped to avoid, it seems we have to allow this.

I know it’s possible to disable e-mail address verification, but then it will be the case for every user, and that’s something we don’t want.

We are currently already using an Azure B2C connector and we could look up if the e-mail address is allowed to sign up, without e-mail verification. So ideally we would love to make this conditional (e-mail verification is not needed in case an e-mail address has been marked as pre-approved). Is this behavior even possible, or not?

Is there an option to have two different user flows, maybe?
(we want to limit functionality for users that have not verified their e-mail address)

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    While the answer of Ali definitely is the most structural and robust approach to the problem, I want to point out a work around that seems to work good for me as well.

    I have created a second policy (same claims , same API connector deployment, same secrets , etc). There, I am just marking the email address not to require verification, in the Page Layout.

    However, I have created two API connector types. Pointing to the same API deployment, but with passing a query parameter (&emailVerified=true or &emailVerified=false) to the connector. In the connector logic, I do the specific validation and persist the flag with my user profile, so I can know in the future if a profile has been verified or not.

    Once the user is signed up, I can easily leverage the same login policy as before, just knowing that in the Claims, there is a different tfp claim that could also be used for verification.


  2. 0

    Yes, this is possible and straightforward. You can first collect email address only from the user using a self-asserted technical profile. Then you call your REST API endpoint to check if this user should go through verification or not. Here is sample code to collect email only and then make a conditional decision:

    https://github.com/azure-ad-b2c/samples/tree/master/policies/dynamic-sign-up-sign-in

    Your first orchestration step would be:

       <OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="CheckIfVerificationNeeded-Exchange"
          TechnicalProfileReferenceId="CheckIfVerificationNeeded" />
      </ClaimsExchanges>
    </OrchestrationStep>

    You should set up a claim called IsVerificationRequired. The value should get set by your API response as an OutputClaim.

    You need the self-asserted technical profile to collect the email. That technical profile should call your REST API technical profile as a validation technical profile.

    Later on in your user journey, you only display verification if IsVerificationRequired = true.

    It would look something like this:

        <OrchestrationStep Order="X" Type="ClaimsExchange">
          <Preconditions>
           <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>IsVerificationRequired</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="EmailVerification-Exchange"
              TechnicalProfileReferenceId="EmailVerification" />
          </ClaimsExchanges>
        </OrchestrationStep>

    You can make this cleaner and more sophisticated using SubJourneys, which I highly recommend. However, I have kept this simple to convey the concept.

    I would greatly appreciate if you can select this answer if it resolved your issue. Thanks!

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search