Microsoft have released a new feature to the Identity Platform to allow you to configure Configure a custom email provider for one-time passcode events 🔗 within a custom authentication extension for an external tenant.
At the time when we started to implement this feature, it was still in preview, meaning we had no blogs like this to help. We ended up having to raise a support ticket with Microsoft to assist in getting this resolved.
This is not a full guide on setting this up. If you would like one, the Microsoft documentation above does explain all of the steps.
Our setup for this is a workforce tenant with Front Door, APIM and the API, and then an external tenant which is set up with the custom authentication extension.
What Was The Problem?
The error message that we received was the following when trying to test the user sign-in/sign-up flow:
There was an issue looking up your account. Tap Next to try again.
Honestly, one of the most misleading error messages that left us chasing our tails for quite some time. This error message can and does occur whether the account already existed or not, so nothing to do with not being able to look up the account.
Several hours of checking all of the configurations in B2C later, I decided to move on and check the other side, the Workforce Tenant.
From the diagram above, the first thing to check is Azure Front Door (AFD) and the Web Application Firewall (WAF) that is configured alongside that. Let’s have a look at the logs:
In our setup, the WAF has an IP Restriction rule on it to only allow traffic from certain IP addresses, mainly our corporate VPN. This is to help control the access to the development and test environments. The WAF logs are showing that the request is being blocked by the IP filtering rule. Entra has a lot of IPs that the traffic could originate from, so to get around this I updated the rule to not block if the request matched our OTP endpoint.
From here, another test showed that the request was now being allowed through, but we were still getting the same error message. The next step in our chain was to check API Management (APIM). Looking at the logs, I could see that the API was not returning any errors, but it was not returning the expected response either.
Digging into this further, I started looking at the code itself, and found the culprit. The code, whilst a completely valid function, was not returning the expected response that Entra needed. The code was just returning a standard 200 OK for success.
ResponseObject responseData = new ResponseObject("microsoft.graph.OnOtpSendResponseData");
responseData.Data.Actions = new List<ResponseAction>() { new ResponseAction(
"microsoft.graph.OtpSend.continueWithDefaultBehavior") };
return new OkObjectResult(responseData);This is the key part from the documentation above that had been missed. It has to return the exact object and actions that the B2C flow expects.
Fixing that with the development team and a quick redeploy, and we were able to get the flow working as expected.
Conclusion
Hopefully, this will help anyone else who is trying to set up the custom email provider for one-time passcode events in Entra B2C. If you do have similar issues, I would recommend checking all the steps in your chain one at a time. If you have WAF rules, for example, check the logs or put the WAF in detection mode so you can see the requests and work from there. Double-check the code against the documentation, and make sure to return the correct object and actions that Entra expects.