应用错误收集

我们正在Azure中为面向客户的Web和移动（本机）应用程序构建后端。最初的计划是使用Azure AD来管理用户凭据和身份验证。但是，正如我一直在研究的那样，我发现以下三个事项强烈向我表明，Azure AD并不适用于面向客户的应用程序中的身份验证。

建议的登录方法是重定向到Azure AD登录页面。此页面可以通过公司品牌进行某种程度的定制，但品牌在所有情况下都不会显示。这种登录方法适用于内部公司工具，但对于面向客户的应用程序而言似乎非常俗气;特别是如果该应用程序是本机移动应用程序。这个问题和潜在的解决方法在下面的链接中进行了讨论，但是解决方案感觉就像是一个黑客，似乎与所有已发表在该主题上的文档相矛盾。

Azure AD身份验证要求所有用户都拥有Microsoft帐户，我不想要求我的客户创建Microsoft帐户（如果他们还没有帐户）或者他们想要为我的应用程序使用电子邮件地址这与他们的Microsoft帐户使用的电子邮件不同。
似乎没有一种好方法可以允许从任何域创建具有电子邮件地址的用户。我可以将我的所有客户视为＆＃34;访客用户＆＃34;在Active Directory中，但每次我想在Azure AD中创建新用户时，我都必须使用Active Directories电子邮件邀请系统。这不是我的选择。

我是否正确陈述了这些事实？我是否正确地断定Azure AD不是存储面向客户的应用程序的用户凭据的好选择？如果是，那么为面向客户的应用程序处理身份验证的推荐方法是什么？后端是否在Azure中托管？

非常感谢任何和所有回复！我找不到关于这个主题的任何讨论！

对于您的方案，我建议您将Azure AD B2C用于面向客户的应用程序。

<强> 1。对于用户界面

您还可以使用页面UI自定义功能来自定义任何策略的外观。

<强> 2。对于不同的国内流离失所者

身份提供者是一种对客户进行身份验证的服务身份和问题安全令牌。在Azure AD B2C中，您可以在您的租户中配置许多身份提供商，例如 Microsoft帐户，Facebook或亚马逊等。

3.使用来自任何域的电子邮件地址创建用户

用户可以使用Azure AD B2C注册任何域的任何电子邮件地址。用户创建的这些注册帐户将是本地帐户，并由Azure AD B2C存储。

总体而言，Azure AD用于组织。如果您想直接向客户保护您的应用程序，Azure AD B2C绝对是更好的选择.Auture AD B2C中有许多功能，您可以参考the official document获取更多详细信息。