Azure AD 中的手动代码流

Question

为了结合 Azure Active Directory 创建自定义登录页面，我们希望在向 AD 发送用户和密码时使用代码流（就像 MS 在自己的登录页面中所做的那样）。

目前，在我们的登录页面中，我们正在使用带有 UserCredential 类的 AquireToken 登录用户，但这只能让我们访问和刷新令牌。

UserCredential uc = new UserCredential(userName, password);

result = authContext.AcquireToken(resource, clientId, uc);

Microsoft 提到使用 UserCredential 登录用户是一个坏主意（安全性），但没有提及任何确切原因。此请求是从 Web 服务器向 AD 服务器发出的，因此我在这里看不到任何安全问题。他们确实希望我们购买 Azure AD 的高级版，但以数百万用户计算它太贵了。

欢迎提出任何建议。提前致谢。

Answer 1

让应用在自己的 UI 中收集用户凭据是一种糟糕的安全做法，并且会破坏可用性。以下是其中的一些原因：

1. 它教用户在没有辨别力的情况下将其凭据输入到任何提示中
2. 它不适用于密码管理器
3. 它会阻止用户在其他应用中享受单点登录，或从列表中选择帐户
4. 它会强制用户重新输入凭据，因为他们本来可以通过操作系统或身份验证代理应用程序静默登录。例如，在加入域的 PC 上。
5. 对于已开启双重身份验证的用户，对您的应用的身份验证将失败。
6. 如果您正在构建多租户应用程序，您将失去利用 Azure AD 的家庭领域发现流程的能力。

希望这会有所帮助， 爱丽儿。

Answer 2

如果您的应用要支持 Azure AD 或 Microsoft 帐户（以前称为 Live ID）以外的其他身份，那么短期内您应该在应用中显示其他登录按钮。长期来看：我们正在努力在 Azure AD 上增加对社交 IdP 的支持（这些是我们为 Azure AD 带来的 ACS 功能）。

Re：使用任何电子邮件地址作为登录字符串：您能澄清一下您的意思吗？您是否尝试支持应用程序本地的凭据（而不是依赖于 Azure AD）？如果您分享一些您心目中的体验的模拟，我将很乐意提供反馈。您可以通过 Microsoft.com 上的 myfirstname.mylastname 与我联系。