我尝试在Azure AD方案中实施“资源所有者密码凭据授予”。
我有一个web api(DemoWebApi)和一个声明为本机应用程序的控制台(DemoConsole)。 我能够使“授权代码授权”和“客户端凭据授权”工作,但我遇到了“资源所有者密码凭据授权”的一些问题。
,尤其是NO MSA部分。
所以我在Azure AD租户中创建了一个用户,现在我收到此错误消息:
用户或管理员未同意使用ID为“bd274da6-80f2-458a-b74b -...”的应用程序。发送此用户和资源的交互式授权请求。
我无法弄清楚我应该做什么
这是我的源代码:
string authority = "https://login.microsoftonline.com/7dda5ce2-2fb6-4f82-bc27-...";
AuthenticationContext authenticationContext = new AuthenticationContext(authority, false);
UserPasswordCredential credentials = new UserPasswordCredential(login, password);
AuthenticationResult res = await authenticationContext.AcquireTokenAsync(webApiClientId, consoleClientId, credentials);
答案 0 :(得分:1)
如果您正在使用它作为LoginController操作以提供自定义登录屏幕,那么值得阅读我在处理它时遇到的一个场景。
成功分配一个令牌以获取正确的密码。
您可能需要调用登录控制器来获取访问令牌才能对用户进行身份验证。现在,当您第一次通过AuthenticationContext获取访问令牌时(通过提供所有必需的信息,如客户端ID,资源ID,租户,凭证),您再次想要获取访问令牌,但这次用户提供了错误的密码但正确的客户端id,Azure AD仍然为对象提供访问令牌。 Wola !!!! 我遇到过这个问题,我已经制作了5-10次这个场景,以确保实际发生这种情况。
基于我对Azure AD的理解,我得出结论,Azure AD在其TokenCache中存储访问令牌,并且每当AuthenticationContext对象请求访问令牌时,它甚至在验证传入的密码凭证之前首先查找缓存,尽管它肯定会查找客户端ID哪个令牌已经发出。这是事情开始变得有趣的时候你会意识到他们究竟是如何为错误的密码提供访问令牌(记住:这些场景是你第一次获得访问令牌以获得正确的密码,然后下次使用错误的密码你仍然可以访问使用AuthenicationContext时的令牌)解
如果您有类似的要求,要解决此可能的问题,您需要在从AcquireTokenAsync方法获取AuthenticationResult后立即清除身份验证上下文对象的令牌缓存。
authenticationContext.TokenCache.Clear();
那就是它:)。
我想这从未被记录过,我相信这对任何正在使用资源所有者凭据流设计自定义登录页面的人都有帮助。虽然Azure严格建议使用它提供的其他身份验证流程。
答案 1 :(得分:0)