我们的应用程序（下面称为“XYZ_App”）是一个多租户SaaS应用程序。我们正在将其作为多租户“Web应用程序/ API”（下面称为“AppSourceXYZ_App”）提供给Microsoft AppSource。
我们启动了OpenID Connect实施，当需要/需要多方租用时，根据文档中的说明，端点指向“通用”。
在XYZ_App中，我们在系统中添加了信息，以了解每个XYZ_App租户所关联的AAD实例（使用Microsoft分配给此AAD实例的GUID，我们不使用“rename-safe.onmicrosoft.com”表示）
当使用“常见”端点时，我们必须从JWT手动验证颁发者，以确保它是预期的：用户可以访问XYZ_App，请求访问与contoso.onmicrosoft.com关联的XYZ_App租户，获取指示到“login.microsoftonline.com/common”进行身份验证，然后决定与来自另一个AAD实例的用户进行身份验证（下面称为“anotherAADInstance.onmicrosoft.com”）。在这种情况下，即使用户可以在anotherAADInstance.onmicrosoft.com上成功进行身份验证，XYZ_App的重定向URI也必须确保JWT颁发者是来自contoso.onmicrosoft.com的发布者。我将此设置称为Scenario_1。
考虑到这种情况，我们考虑不使用“common”并自动定制登录login.microsoftonline.com的请求;试图“jail”请求被强制对特定的AAD实例进行身份验证。我们仍然需要在重定向URI中执行验证以确保发行者是合适的，但我们认为这种方法可能会让我们的生活更轻松。我将此设置称为Scenario_2。
您认为Scenario_2从长远来看是否可行还是太短视了？根据我目前对OpenID Connect的了解，我在Scenario_2中可以看到的一个限制是，在我们的应用程序中支持“经纪人帐户”会有问题。
“经纪人账户”的解释：在我们的行业中，允许一些外部用户访问系统。假设我有一家名为“BrokerCo”的公司（拥有自己的brokerco.onmicrosoft.com AAD实例），拥有2名员工：Broker1和Broker2。另外，AADInstance和contoso聘请Broker1和Broker2来获取代理服务以在XYZ_App中执行任务;要求XYZApp授予他们访问权限。从OpenID Connect角度进行身份验证的理想方式是什么？如果XYZ_App使用“login.microsoftonline.com/common”进行身份验证（如Scenario_1中;与Scenario_2中的“jailed”访问相反），Broker1和Broker2可以通过brokerco.onmicrosoft.com进行身份验证（无AAD“外部用户） “对于anotherAADInstance也不是contoso”，但是他们会使用与XYZ_App的anotherAADInstance和contoso租户配置的发行者不同的重定向URI ...我觉得我回到了正方形1 ...
您是否有解决此问题的建议或指示？
背景背景： 在使用OpenID Connect发行者时，我收到以下错误消息： AADSTS50020：来自身份提供商“https://sts.windows.net/XXXXXXXX-fake-GUID-9bZZ-XXXXxxxxXXXX/”的用户帐户“testuser@anotherAADInstance.onmicrosoft.com”在租户“XYZ发布者”中不存在，并且无法访问该租户中的应用程序“YYYYYYYY-fake0-GUID-YYYYyyyyYYYY”。该帐户需要首先作为外部用户添加到租户中。注销并使用其他Azure Active Directory用户帐户重新登录。
提前致谢！
答案 0 :(得分：0)
您的问题有多个层次，试图解决其中大部分问题：
AppSource 是关于新用户的试用体验：这意味着全球任何公司帐户都可能成为您SaaS应用程序的用户 - 或者至少是您应用程序的试用体验，因此在与AppSource集成时，您需要考虑的第一件事是让潜在用户第一次体验您的应用程序是多么容易。
考虑到这一点，AppSource建议应用程序试用版的构建方式允许任何组织的任何用户登录，因此适用于您的应用程序的多租户方法是任何应用程序的推荐设置。
单租户方法需要您更多控制，并且对于试用体验 - 这意味着用户无法立即尝试您的应用程序，因为您必须对您的单个操作进行操作租户应用程序是将用户作为来宾用户添加到Azure Active Directory租户。然后，此来宾帐户将需要等待接收电子邮件以接受加入此租户的邀请，然后您要添加用户然后登录到您的应用程序。
因此，您的方案1 是考虑一般试用体验的最佳方案，并且通常也需要较少的管理（因为您不需要创建/管理需要的每个个人帐户）以Azure AD实例的访客用户身份访问您的应用程序。）
但是您列出的一些问题 - 此方案带来的有效：因为您接受公共端点，您基本上说任何用户都可以登录到您的应用程序的任何租户，并且这可能是不可取的。此外，您列出的用户可以为任何应用程序生成令牌的方案也是有效的，但是，您可以添加其他检查以使其更安全，并且阻止由另一个身份验证生成的任何令牌：
您可以验证“受众群体”声明，以保证令牌已发放到您的应用
您最终可以检查数据库中租户ID列表的'tid'/'iss'声明，看看用户的组织是否是您应用程序中的有效组织 - 这对于非审判用户/组织。
this article中的更多信息。
关于方案'2'和经纪人帐户：
这种情况可以用两种不同的方式解释：
如果您的案例为“1”，那么您是对的：如果您的应用程序需要对属于另一个Azure AD租户的访客用户进行身份验证，则无法直接使用公共端点。
如果您的案例是“2”，那么您需要做的是继续使用公共端点，并在用户通过身份验证后请他们选择公司。我在没有完全理解这种情况的情况下用通用术语来描述它。也许这并不简单，因为您希望远程公司控制此而不是用户 - 因此可能需要在此处理一些额外的复杂性。
请注意，如果您的方案是方案1. - 理论上 - 您仍然可以使用混合方法，您要求用户在应用程序和他们想要登录的公司内键入用户名，然后检查是否需要针对 common 或 tenant-id 端点验证用户，准备请求，然后在进行身份验证时发送 login_hint 参数。更多信息here