我对与 OAuth 相关的主题有一些困惑，我希望有人可以帮助我解决它们：) 如有任何不妥之处，请随时纠正我。
假设我的网络公司在不同的域上运行着许多网站：
- www.socks.com
- www.boats.com
- www.cakes.com
假设这些是包含一些社交内容的电子商务网站，因此存在存储各种数据点的用户帐户。所以我的公司（我们称之为 ACME 电子商务）已经为不同的客户创建并管理所有这些网站。
现在，我们决定为我们所有的电子商务网站设置一个中央帐户会很方便；好处包括通过允许客户使用其现有帐户登录任何站点来减少摩擦，以及集中信息以提高营销准确性并减少与客户的过度沟通。输入 OAuth！
据我了解，OAuth 是一种身份验证和授权标准。简而言之，身份验证是“登录”，授权是“您可以进行这些 API 调用”，对吗？让我们从身份验证开始：
验证！
这里的想法是您访问 socks.com，当您通常登录时，会有一个“使用 ACME ID 登录”按钮，以及“登录 Socks.com”。您到处都可以看到：使用 Facebook 登录、使用 Google 登录等。所以我们有“使用 ACME ID 登录”。
当用户单击“使用 ACME ID 登录”时，socks.com 直接从 ACME 的 OAuth 服务器请求并接收未经授权的请求令牌，然后将用户的浏览器重定向到 ACME 的 OAuth 站点。在那里，用户插入他的 ACME ID 帐户的用户名和密码，ACME OAuth 授权请求令牌并通过重定向 URL 将其返回到 socks.com。
所以此时，Socks.com 知道用户已登录到 ACME ID。如果 Socks.com 想要从 ACME 的 Resource API 查询信息，它会将其授权的请求令牌交换为访问令牌，然后进行调用，但我们只是在谈论身份验证，并且用户已经通过身份验证。正确的？
假设我有这个权利，即使我有一点点错误，Socks.com 在这一点上会做什么？由于在这种情况下，它有自己的用户数据库，它是否将中央 OAuth 身份验证与自己的数据库同步？Socks.com 现在知道 joe@blow.com 已登录，它会在其数据库中查询该电子邮件地址以获取他的购买历史记录和最后购物车内容？它为 joe 维护一个会话，如果该会话过期，那么他必须再次使用他的 ACME ID 进行身份验证？
我知道 Spotify 会做这样的事情；他们有“用 Facebook 登录”。如果我选择这个选项，Facebook 域上会弹出一个带有登录窗口的小浏览器窗口。我登录，弹出窗口关闭，Spotify 显示我已登录……我的 Facebook 电子邮件地址和一个由 8 个左右随机数字组成的帐户名。这似乎是 Spotify 看到我通过 Facebook 的 OAuth 服务器进行了身份验证，然后在他们自己的系统中为我生成了一个新帐户。随后的 Facebook-OAuth 身份验证/登录每次都会让我进入同一个 Spotify 帐户。
如果有的话，我在这里有什么问题吗？
因此，通过使用 ACME ID 的中央身份验证设置，我们可以允许用户使用相同的 ID 登录 socks.com、boats.com 和 cakes.com，并且我们将礼貌地在每个位置为他们创建帐户。这是行动中的摩擦减少，但地址和信用卡数据仍然分开存储，所以我们没有得到集中化的好处。但是，这超出了身份验证，我们进入了授权！
授权！
因此，我们进行了一些帐户数据重组，并将所有客户的地址和信用卡数据转移到他们的中央 ACME ID 帐户中。我们建立了一个 API 来请求和修改这些信息。现在，当 cakes.com 使用 ACME ID 进行身份验证并获得其授权的请求令牌时，该令牌将被交换到 ACME OAuth 服务器以获得 API 的访问令牌。（这存储在服务器端，在用户的会话数据或其他东西中。）
现在，当用户在 cakes.com 上结账时，我们可以对 ACME 资源服务器进行 API 调用，传入 ACME ID 用户名，以检索客户地址数组，然后使用它来填充网页。嘿嘿，服务真好！Cakes.com 被OAuth 程序授权做这种事情。
我那里有一切吗？
边缘案例！
上面的带有中央 OAuth 服务器的电子商务网站的实现非常明确，但是有一些“边缘情况”可能会以不同的方式实现：
1) 没有分布式用户帐户
如果我想强制 socks.com、boats.com 和 cakes.com 的所有用户仅使用 ACME ID 登录怎么办？也许每个站点都有一个“用户帐户”，其中包含购买数据和地址数据等，具有关联的用户名，但没有密码，也没有实际的登录机制。一旦 ACME ID 通过身份验证，会话就会被标记为“已登录”。
或者，也许所有信息，如购买历史、地址和 CC #s 都聚合到 ACME 资源端点中，而卫星电子商务网站上没有存储有关客户的信息？好吧，那么卫星基本上是奴隶，使用 ACME OAuth 作为远程数据库。然后，因为购买历史是集中的，你或多或少需要集中你的物品，然后也许它会归结为“什么不是集中的？” 和“为什么有单独的网站”——除非它们需要分开。
那么，这有什么好处吗？
2) 用于移动应用的无 UI Web API
假设您正在构建 iOS/Android/等。名为 Horses 的应用程序，您需要在云中存储一些有关您的用户的信息，特别是他们真正喜欢的马匹。尽管任何人都认为马与袜子、船和蛋糕无关，但您希望允许您的用户使用他们的 ACME ID 以及您发明的 Horses ID 登录。
现在，您基本上采取在 www.horses.com 域上拥有卫星用户帐户系统的路线，并可选择允许该人使用 ACME ID 登录并优雅地创建一个 horses.com 帐户以存储他们的 horses.com - 相关数据。相当标准；一个区别是您实际上不需要构建网站，它只是一个 API。
但是，如果您只想允许 ACME ID 作为登录名，而没有 horses.com 帐户怎么办？因此，当您转到 Login 时，您的 horses.com API 将使用 ACME OAuth 启动 OAuth 舞蹈，进行身份验证，然后将访问令牌（用于 horses.com）传递给应用程序。该访问令牌将用于根据您的用户在应用程序中喜欢的马匹对 horses.com 进行读取和写入 API 调用。我在这里是正确的吗？
3) 中央授权访问多个站点
让我们采用这个设置：ACME ID 包含用户名、密码、电子邮件、信用卡和账单信息。Socks.com、boats.com 和 cakes.com 具有购买历史，以及有关此人在这些网站上做过哪些与袜子相关、船相关或蛋糕相关（分别）的事情的社会信息。
现在我们想要制作一个使用 ACME ID 进行身份验证的移动应用程序，并且可以从 ACME ID 的资源 API（用于 CC 和计费数据）以及每个使用 ACME ID 进行身份验证的站点中提取信息。通过这种方式，我们可以将袜子、船和蛋糕完美融合，然后我们可以向客户收费！（你明白了。）
所以……这怎么可能？
- 从 ACME OAuth 服务器接收对卫星站点的 API 有用的访问令牌？
- 在每个卫星站点分别进行身份验证，使应用程序只能获取与船和蛋糕相关的内容，因为用户不想在网上发布他的袜子照片？
- 还有什么办法？
谢谢阅读！