ADAL iOS-已验证其他用户。预期的[e-mail]，实际的[e-mail] [英] ADAL iOS - Different user was authenticated. Expected [e-mail], actual [e-mail]

问题描述

我正在使用ADALiOS来访问OneDrive商业服务，并且在帐户歧义消除后使用下面的代码段对用户进行身份验证，

I am using ADALiOS to access OneDrive for business service, and I use below snippet to authenticate a user after account disambiguation,

    ADAuthenticationContext *context = ....

   [context acquireTokenWithResource:resource
                             clientId:clientId
                          redirectUri:redirectUri
                       promptBehavior:AD_PROMPT_ALWAYS
                               userId:@"[e-mail]"
                 extraQueryParameters:@""
                      completionBlock:^(ADAuthenticationResult *result) {
                      ...
                      }

Web身份验证UI将提示，并允许用户输入凭据以继续。这里的问题是，在此页面中，用户还可以将用户ID更改为 [e-mail]，并且将调用完成块，并显示诸如已验证不同的用户。期望的[e-mail]，实际的userB之类的错误。 @ mydomain.com。我使用ADALiOS错了吗？

The web authentication UI will prompt, and allow user to input credential to continue. The issue here is, in this page, user can also change the user id to "[e-mail]", and completion block will be invoked with a error like "Different user was authenticated. Expected [e-mail], actual [e-mail]". Am I using ADALiOS wrong?

推荐答案

当您指定userId时，ADAL会假定已指定该名称，因为那确实是该用户你自找的。如果结果用户不是所要求的用户，则您将看到错误。如果您不在乎哪个用户已通过身份验证，则可以将nil作为userId参数传递，并且不会收到错误。

When you specify a userId, ADAL assumes that it was specified because that was truly the user that you wanted. If the resulting user is not the one that was asked for, then you get the error you are seeing. If you don't care which user is authenticated then you can pass nil as the userId parameter and you won't get the error.

ADAL库从过多的谨慎。尽管userId参数暗示了什么，但是当您调用ADAL时，ADAL无法保证您将为所请求的用户获得令牌。会做到最好。如果它可以在缓存中找到该用户的令牌，则它将返回它。但是，如您所见，如果调用了交互式流程，则不会阻止用户输入与要求的用户名不同的用户名。在这种情况下，将返回另一个用户的令牌。如果应用程序已将某些UI元素或私有资源与特定的userId相关联，会发生什么？如果它获得的令牌与请求的用户不同，则可能是混合用户的方式对应用程序用户而言并不明显。如果用户最初以低权限用户身份登录，但随后以管理员身份登录，而该应用没有注意到这一点，则可能会发生不良情况。因此，该库假定如果您要求一个特定的用户，那么那是唯一可以接受的用户。

The ADAL library does this out of an over abundance of caution. Despite what the userId parameter implies, when you call ADAL there is no way for ADAL to guarantee that you will get a token for the user that you asked for. It will do it's best. If it can find a token for that user in the cache then it will return it. However, as you've seen, if the interactive flow is invoked, nothing prevents the user from entering a different username than the one that was asked for. In that case, a token for a different user will be returned. What happens if the app has associated some UI elements or private resources with a particular userId? If it get's a token for a different user than was asked for, then it might be mixing users in a way that is not obvious to the user of the app. If the user originally signed in as a low privilege user, but subsequently signed in as an admin, and the app doesn't notice this, then bad things may happen. So, the library assumes that if you asked for a specific user, then that is the only user that is acceptable.

接下来的内容可能比您需要的更多，但仅仅是为了完整，我将继续。不幸的是，出于三个不同的目的，已重载了userId参数。

What follows is probably more detail than you need but just to be complete I will continue. The userId parameter is unfortunately overloaded for three different purposes.

1. 作为缓存查找键。如果ADAL先前已对传递的用户进行身份验证，并且在缓存中具有该用户的令牌或刷新令牌，则它可以直接查找该令牌，而无需任何AAD请求。如果您一次只对一个用户进行身份验证，则不会增加任何值，因为ADAL会尝试查找对所传递资源有效的令牌。

1. As a cache lookup key. If ADAL has previously authenticated the passed user, and has a token or refresh token for that user in the cache, then it can look up that token directly and avoid any need for an AAD request. If you only ever authenticate a single user at a time, then this doesn't add any value as ADAL will attempt to find a token valid for the resource that was passed.

作为服务器的登录提示。 userId用于预填充用户名字段，以方便用户使用。但是，用户可以自由删除该用户名并提供其他用户名。

As a login hint to the server. The userId is used to prefill the username field as a convenience to the user. However, the user is free to erase that username and provide a different one.

作为家庭领域发现的提示。如果用户是联盟用户，则意味着AAD需要引用ADFS（或某些其他联盟服务器）进行身份验证，它需要一个用户名来确定应引用的服务器地址。通常，这是通过两步过程完成的。用户首先登陆AAD页面并输入其用户名。一旦用户名字段失去焦点，服务器就会查找用户名，如果它是联合用户，它将开始将其重定向到其ADFS服务器。最后，用户登陆ADFS登录页面，他们发现其用户名已填写。输入密码并完成身份验证。但是，如果传递userId参数，则其值将传递给AAD。因此，AAD不再需要等待用户键入用户名，就可以将其直接发送到其联合身份验证服务器，从而消除一页，并允许用户直接登录。

As a hint for home realm discovery. If the user is a federated user, meaning that AAD needs to refer to ADFS (or some other federation server) for authentication, it needs a username to determine the address of the server to which it should refer. Normally this is done via a two step process. The user first lands on an AAD page and types their username. As soon as the username field loses focus the server looks up the username, and if it is a federated user, it starts redirecting them to their ADFS server. Finally, the user lands on the ADFS login page and they find their username already filled in. They enter their password and authentication completes. However, if you pass a userId parameter its value is passed to AAD. As a result, AAD no longer needs to wait for the user to type their username and can send them directly to their federation server, eliminating one page, and allowing the user to go directly to signing in.

如果您需要2或3，但您不在乎1，则有一种解决方法。您可以为userId指定nil，但是将 login_hint = username作为extraQueryParameters参数添加。将 username替换为您将在userId参数中传递的用户名。如果执行此操作，则ADAL将忽略用户已要求，但AAD会将用户名解释为登录提示以预填充用户名字段，并解释为家庭领域发现提示。将确保用户要求的是返回用户的检查将被绕过。请注意，您可能无法获得作为登录名（login_hint）提供的用户的令牌。应确保在验证用户身份之前，先对其进行身份验证。

If you need 2 or 3, but you don't care about 1 there is a workaround. You can specify nil for the userId but add "login_hint="username" as the extraQueryParameters parameter. Replace "username" with the username you would have passed in the userId parameter. If you do this, then ADAL will be oblivious to the user you have asked for, but AAD will interpret the username as a login hint to prefill the username field, and as a home realm discovery hint. The check to ensure that the user asked for is the user returned will be bypassed. You need to be very aware that you may not get a token for the user you provided as the login_hint. You should ensure that you verify the user before making any assumptions about who they are or what they might have access to.

这篇关于ADAL iOS-已验证其他用户。预期的[e-mail]，实际的[e-mail]的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！