Azure AD中的手动代码流

时间:2015-03-09 10:46:52

标签: azure active-directory oauth-2.0

在我们寻求与Azure Active Directory结合创建自定义登录页面时,我们希望在向AD发送用户和密码时使用代码流(如MS在自己的登录页面中所做的那样)。

目前,在我们的登录页面中,我们使用AquireToken和UserCredential类来记录用户,但这只会给我们访问和刷新。

UserCredential uc = new UserCredential(userName, password);

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

微软已经提到使用UserCredential登录用户是一个坏主意(安全性),但没有提到任何确切的原因。此请求是从Web服务器到AD服务器的,因此我在这里看不到任何安全问题。他们确实希望我们购买Azure AD的高级版本,但是它的价格过高,计算数百万用户。

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

2 个答案:

答案 0 :(得分:0)

让应用程序在自己的用户界面中收集用户凭据是一种糟糕的安全措施,并且会破坏可用性。以下是一些原因:

  1. 它教会用户在没有识别的任何提示中输入他们的凭据
  2. 它不适用于密码管理器
  3. 它阻止用户享受与其他应用的单点登录,或从列表中选择帐户
  4. 它强制用户重新输入凭据,这些凭据可以由操作系统或身份验证代理应用程序以静默方式登录。例如,在加入PC的域中。
  5. 对于已启用双因素身份验证的用户,对您的应用进行身份验证将失败。
  6. 如果您正在构建多租户应用,则您将无法利用Azure AD的主域发现流程。
  7. 希望这有帮助, 爱丽儿。

答案 1 :(得分:0)

如果您的应用支持除Azure AD或Microsoft帐户(以前的Live ID)之外的其他身份,那么在短期内您应该在应用中显示其他登录按钮。更长期:我们正在努力在Azure AD上添加对社交IdP的支持(这些是我们将其带入Azure AD的ACS功能)。

Re:使用任何电子邮件地址作为登录字符串:你能澄清一下你的意思吗?您是否尝试支持应用程序的本地凭据(而不是依赖Azure AD)?如果你分享一些你所经历的经验,我会很乐意提供反馈。您可以通过Microsoft.com上的myfirstname.mylastname与我联系。