为了处理身份验证/授权，我们原本计划实施Owin OAuth，但后来发现'Thinktecture IdentityServer3'更适合我们的需求。确实如此。'Thinktecture IdentityServer3'是OpenID Connect的一种实现，而OpenID Connect是OAuth加上“身份层”的组合。您仍然可以使用OAuth进行授权（访问受保护的资源），因为OpenID提供者通常会返回一个访问令牌(access_token)。它还返回一个id_token以进行身份验证(身份确认)。
如果租户在任何区域实例（例如'NA1.ourwebsite.com'）中拥有帐户，则不仅应该能够通过'NA1.ourwebsite.com'登录，而且还应该能够通过集中式实例/身份服务器'ourwebsite.com'登录。这是OpenID Connect可以实现的用例。您将能够给最终用户选择是否使用NA1.ourwebsite.com、ourwebsite.com或任何其他OpenID Connect提供程序登录。例如，我能够使用多个提供程序登录同一StackExchange帐户。
当然，最终用户需要将每个OpenID Connect身份与您的应用程序中的账户关联起来。有时，您的应用程序可以根据OpenID Connect声明（例如电子邮件）自动确定此关联，而其他情况下，最终用户必须手动关联登录信息。例如。
目前，我们为每个租户拥有不同的数据库，并且他们的用户信息也存储在各自的数据库中。
未来有很多方法可以采取。您需要区分仅适用于您的应用程序的用户信息和适用于身份验证的用户信息。您不能合理地期望所有OpenID Connect提供者存储您的应用程序所需的所有用户信息。关于用户信息，它只能验证您的用户身份并提供您的用户已经在提供者中存储的个人资料信息（例如，Twitter账户中的内容）。
我不确定一个应用程序如何拥有多个身份服务器（是否必须选择联合服务器）。
这有点像一个机场接受多种身份证件的方式：出生证明、电费单、护照、驾驶证。虽然很难理解，但一旦您了解了id_token就像是可信身份证件的一部分，您就可以开始欣赏它了。真实的例子是出生证明。在这种情况下，政府是身份提供者，而出生证明就是id_token。应用程序可以选择接受哪些身份提供者。
SalesForce.com 也能实现同样的功能，但我不知道具体如何操作。有人可以帮我吗？
除了 salesforce.com，如上所述，stackexchange.com 也能实现此功能。OpenID Connect 规范中的图表会对此有所帮助。
+--------+ +--------+
| | | |
| |---------(1) AuthN Request-------->| |
| | | |
| | +--------+ | |
| | | | | |
| | | End- |<--(2) AuthN & AuthZ-->| |
| | | User | | |
| RP | | | | OP |
| | +--------+ | |
| | | |
| |<--------(3) AuthN Response--------| |
| | | |
| |---------(4) UserInfo Request----->| |
| | | |
| |<--------(5) UserInfo Response-----| |
| | | |
+--------+ +--------+
- RP（客户端）向OpenID提供程序（OP）发送请求。
- OP对终端用户进行身份验证并获得授权。
- OP响应带有ID令牌和通常是访问令牌的请求。
- RP可以使用访问令牌向UserInfo端点发送请求。
- UserInfo端点返回有关终端用户的声明。
OP是OpenID Connect提供商。我认为这就是您所说的“身份服务器”。您可以接受来自应用程序决定信任的任何提供程序的令牌。终端用户在登录时可以选择要使用哪个提供程序（通常会看到选择使用Twitter，Facebook，Google，Microsoft等登录）。其中一个选项可能是ourwebsite.com。
RP是依赖方，这种情况下是您的应用程序。它被称为依赖方，因为它依赖各种OP进行身份验证、授权和某些用户配置文件存储。
步骤（1）到（3）几乎与OAuth授权流程完全相同，其中最终用户登录所选择的提供程序，提供程序响应令牌。 OpenID Connect的区别在于，在第（3）步中，响应通常除了
access_token之外还包含一个
id_token。
access_token代表最终用户的
授权。它是OAuth beaker令牌。您的应用程序将其包括在请求受保护的资源时。这些受保护的资源可能包括存储在OpenID Connect提供程序中的用户信息。请参见步骤（4）和（5）。
id_token 表示终端用户的
认证，包含有关终端用户和 Open ID Connect 提供程序的声明。
iss 声明标识 OpenID 提供者，
sub 声明唯一标识终端用户，
aud 声明标识 Relying Party（您的应用程序）。其他标准声明包括经过身份验证的终端用户的
name、
given_name、
family_name、
middle_name、
picture、
website、
email、
phone_number。
对于授权而言，最重要的是
sub 和
iss，因为这两者的组合唯一地标识了登录。
OpenID Connect 很复杂，需要一些时间来完全理解。您的坚持将会得到回报，因为它完美地匹配了您的用例。
Thinktecture IdentityServer3 看起来是一个可靠的选择。另一个类似的选择是
AspNet.Security.OpenIdConnect.Server。
参考资料
OpenID Connect in a nutshell。这篇文章由OpenID Connect的作者之一撰写，包含两个特别有帮助的部分：“发出OpenID Connect请求”和“接收OpenID Connect响应”。
OpenID Connect Core 1.0 incorporating errata set 1。其中一个规范文档，包含在本答案中发布的有用图表。
The OAuth 2.0 Authorization Framework: Bearer Token Usage。OAuth RFC，解释如何在请求受保护资源时使用access_token。
