问题实际上是，例如，为JWT服务的身份验证服务器如何被同一公司或域的多个网站使用(将网站作为子域)使用？不适合公众。
我已经在考虑不对称的 JWT。另外，我不想实现 OAuth 2.0 以避免复杂性，并且因为身份验证服务器只会为属于同一根域的子域的 Web 应用程序提供服务。
本文的当前描述寻求不太复杂的解决方案
如果您想要一种可靠且安全的方式来在不同站点之间共享资源，您可能需要查看 IdentityServer。
简而言之，您基本上将匿名用户重定向到身份服务器进行登录。登录成功后，它将向用户返回一个令牌。然后，用户使用该令牌访问来自不同站点的资源。
在我的 GitHub 示例项目中查看基本工作流程和屏幕截图。
好的，这就是交易。
多个 Web 应用是否可以访问同一个数据库(标识数据库或其他数据库)？ 答案是肯定的！ 现在，如果您使用的是实体框架(我假设您是，尽管没有说明)，那么就迁移等而言，这可能会变得棘手。 就个人而言，我使用Dapper，所以我永远不必担心：-)
是的，每个应用程序都可以访问数据库，但这与您真正谈论的SingleSignOn不同。您希望用户登录到一个站点，并且该标识保留到其他完全不同的站点。 这并不像简单地访问数据库那么简单。 出于多种原因，IdentityServer实际上是此类事物的标准。
不，ajax 方法将不起作用，因为当用户在站点 1 登录时，cookie 适用于站点 1。 如果他访问站点 2，即使您通过 ajax 发送了凭据，浏览器也不会有任何与站点 2 关联的 cookie。 当这一切发生时，用户在站点 1 上，因此所有 cookie 都是站点 1 cookie，与站点 2 cookie 完全分开。 即使你能找到一种方法来完成这项工作，也会带来严重的安全风险。
你可以想象使用隐藏的IFrames而不是ajax来做这样的事情，因为你可以在那里设置iframe网站的cookie。 但我不建议您这样做，因为存在安全风险。
您需要将"身份验证"的概念与"授权"甚至"用户管理"的想法分开。
身份验证----我是我说的那个人吗？ (检查我的用户名和密码，甚至可能是短信等其他表格)
授权----好的，你知道我是谁，但是我可以在你的网站上做什么？ 这可能因站点而异。 也许我是您其中一个站点的管理员，但只是另一个站点的普通用户。 我个人站点 cookie 将包括角色等，并且每个站点都不同。
用户管理----我可以更改我的姓名/电子邮件/等吗？
处理此问题的最佳方法是使用运行 IdentityServer 的单独服务器应用程序。 这将处理身份验证并同时为您的所有站点构建 Cookie。 理想情况下，您还应该将其用于任何用户管理，但这可能会很痛苦，而且并不那么重要。 下面是 IdentityServer4 的一些示例应用。
对您的更新 2 的响应----
不完全是。。。 以下是基本流程：用户转到站点 1 并单击"登录"。 这将触发一个"挑战"，将他们重定向到网站身份验证。 在网站身份验证上，用户通过表单发布提交其凭据(用户名/pw)。 这会将他们登录到网站身份验证，但随后还会将用户重定向回原始呼叫应用程序(在本例中为 site1)，其中包含他们需要的一切。 假设用户现在转到 site2，他们已经登录了!! 使用IdentityServer4，用户将自动登录到所有站点排序。 您不必按照他们描述的方式做额外的事情，只需插入必要的内容，让 IdentityServer4 处理其余的工作。
听着，我知道IdentityServer4可能看起来有点吓人，直到我开始使用它之前，它对我来说都是如此。 事实是，所有困难的事情都是为你处理的。 设置它仍然涉及相当数量的配置，但它确实是您正在寻找的最佳解决方案。
查看以下快速入门：https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/Quickstarts
对更新3的响应------
我理解依赖第三方的担忧，以及这似乎是一种有问题的做法，尤其是在安全方面。 我的回答是这样的：
这些人是该领域的专家。 如此之多，以至于即使在Macrosoft提供的基本模板中，IdentityServer也已成为事实上的安全解决方案。
您将提出的任何本土解决方案都将具有比IdentityServer更多的安全漏洞。 这根本不是轻视你。 这些家伙知道他们在做什么。 他们已经这样做了多年。
为什么要重新发明轮子？ 您将花费 10 倍(至少)尽可能多的工时试图想出一个最终仍然不会那么好的替代方案。
如果您正在做的是基于单个网站cookie的身份验证，那么使用身份确实没有必要。 身份可以做到这一点，但还有其他简单的选择。 但是当涉及到多个站点和SSO时，我真的不能强调这一点，IdentityServer是要走的路。
答案是微服务身份验证服务，它使用私钥生成 RSA/非对称 JWT，其他服务器每个都有相同的对应公钥来验证 JWT 并检索用户声明。
但是，该解决方案并不能满足以下情况：其他每个服务器都需要一组关于用户的不同声明。
它也不是单一登录方法。所以，我会回来的。
但是OAuth 2.0似乎是答案，但它太复杂了，我不喜欢。