我对与OAuth相关的主题有些疑惑，我希望有人能帮助我解决这些问题:)在任何我不合适的地方，请随时纠正我。
所以，让我们说我的网络公司在不同的域名上运行多个网站：
让我们说这些是带有一些社交信息的电子商务网站，因此用户帐户中有各种存储的数据点。所以我的公司（让我们称之为ACME电子商务）已经为不同的客户创建并管理所有这些网站。
现在，我们认为为我们所有的电子商务网站设立一个中央帐户会很方便;其好处包括通过允许客户使用现有帐户登录任何站点来减少摩擦，以及集中信息以提高营销准确性并减少与客户的过多沟通。输入OAuth！
据我所知，OAuth是身份验证和授权标准。身份验证正在＆＃34;登录＆＃34;和授权是＆＃34;你可以做这些API调用＆＃34;简而言之，对吗？让我们从身份验证开始：
AUTHENTICATION！
这里的想法是你去socks.com，当你通常登录时，有一个＆＃34;登录ACME ID＆＃34;按钮，以及＆＃34;登录Socks.com＆＃34;。你到处都可以看到这一点：用Facebook登录，用谷歌登录等等。所以我们有＆＃34;用ACME ID登录＆＃34;。
当用户点击＆＃34;使用ACME ID登录＆＃34;时，socks.com直接从ACME的OAuth服务器请求并接收未经授权的请求令牌，然后将用户的浏览器重定向到ACME＆ ＃39; OAuth网站。在那里，用户插入其ACME ID帐户的用户名和密码，ACME OAuth授权请求令牌并通过重定向URL将其返回到socks.com。
所以此时，Socks.com知道用户已登录ACME ID。如果Socks.com想要查询来自ACME的资源API的信息，它将交换其授权请求令牌以获取访问令牌，然后拨打电话，但我们只是在谈论身份验证，并且用户已经过身份验证。正确？
假设我有这个权利，即使我有点错误，Socks.com在这方面做了什么？因为在这种情况下，它有自己的用户数据库，它是否将中央OAuth身份验证与其自己的数据库同步？ Socks.com现在知道joe@blow.com已经登录，它会在数据库中查询该电子邮件地址，以获取他的购买历史记录和最后购物车内容？它为joe维护一个会话，如果该会话到期，那么他必须再次使用他的ACME ID进行身份验证？
我知道Spotify会做这样的事情;他们有＃34;登录Facebook＆＃34;。如果我选择此选项，则会在Facebook域上弹出一个带有登录窗口的小浏览器窗口。我登录，弹出窗口关闭，Spotify显示我已登录...我的Facebook电子邮件地址，以及一个由8个左右的随机数组成的帐户名。这似乎是Spotify看到我通过Facebook的OAuth服务器进行身份验证，然后在他们自己的系统中为我生成一个新帐户。随后的Facebook-OAuth身份验证/登录会让我每次都进入相同的Spotify帐户。
如果有的话，我在这里有什么不对？
因此，通过使用ACME ID的中央身份验证设置，我们可以允许用户使用相同的ID登录socks.com，boats.com和cakes.com，我们将在每个位置礼貌地为他们创建帐户。这是减少摩擦力的行动，但地址和信用卡数据仍然是分开存储的，因此我们无法获得集中化的好处。但是，这超出了身份验证范围，我们已经授权了！
AUTHORIZATION！
因此，我们进行了一些帐户数据重组，并移动了所有客户＆＃39;地址和信用卡数据到他们的中央ACME ID帐户。我们建立了一个API来请求和修改此信息。现在，当cakes.com使用ACME ID进行身份验证并获取其授权请求令牌时，该令牌将交换到ACME OAuth服务器以获取API的访问令牌。 （这是存储在服务器端，存储在用户的会话数据中。）
现在，当用户在cakes.com上结账时，我们可以向ACME资源服务器发出API调用，传入ACME ID用户名，以检索客户地址的数组，然后使用填充网页。嘿，这是一个很好的服务！ OAuth程序使用Cakes.com 授权来执行此类操作。
我能把所有东西都放在那里吗？
边缘案例
上述具有中央OAuth服务器的电子商务网站的实施非常明确，但有一些边缘情况＆＃34;事情可能以不同的方式实施：
1）没有分布式用户帐户
如果我想强制socks.com，boats.com和cakes.com的所有用户仅使用ACME ID登录，该怎么办？也许会有一个＆＃34;用户帐户＆＃34;在每个站点，包含购买数据和地址数据等，具有相关的用户名，但没有密码，也没有实际的登录机制。会话标记为＆＃34;已登录＆＃34;一旦ACME ID被验证。
或者，购买历史记录，地址和CC＃等所有信息都可能汇总到ACME资源端点，而且在卫星电子商务网站上没有关于客户的信息存储？那么，卫星基本上是奴隶，使用ACME OAuth作为远程数据库。然后，由于购买历史是集中的，您或多或少需要集中您的项目，然后它可能会归结为什么不集中？＆＃34;和＆＃34;为什么有单独的网站＆＃34; - 除非他们需要分开。
那么，这有什么好处吗？
2）用于移动应用的无UI Web API
让我们说你正在构建一个iOS / Android /等。应用程序称为Horses，您需要在云中存储有关您的用户的一些信息，特别是他们真正喜欢的马匹。尽管有人认为任何人都可能因为马匹与袜子，船只和蛋糕无关，但您希望允许您的用户使用他们的ACME ID以及您发明的马匹ID进行登录。
现在，您基本上采取了在www.horses.com域上拥有卫星用户帐户系统的路线，并可选择允许此人使用ACME ID登录并慷慨地创建一个horses.com帐户，以便他们存储他们的horses.com相关数据。很标准;一个区别是你实际上并不需要建立一个网站，它只是一个API。
但是，如果您只想允许ACME ID作为登录，没有horses.com帐户怎么办？因此，当您进入登录状态时，您的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进行身份验证的每个站点提取信息无论如何。通过这种方式，我们可以很好地融合袜子，船只和蛋糕，然后我们可以为客户收取费用！ （你明白了。）
那么......这怎么可能呢？
感谢阅读！
答案 0 :(得分：1)
OAuth 2.0是授权规范，但不适用于身份验证。 RFC 6749，3.1. Authorization Endpoint明确说明如下：
授权端点用于与资源所有者进行交互 并获得授权许可。授权服务器必须 首先验证资源所有者的身份。的方式 授权服务器验证资源所有者（例如， 用户名和密码登录，会话cookie）超出范围 这个规范。
身份验证处理有关＆＃34;谁是＆＃34;的信息。授权处理有关＆＃34;谁授予哪些权限的信息＆＃34;。授权流程包含身份验证作为其第一步。这是人们常常感到困惑的原因。
有许多库和服务使用OAuth 2.0进行身份验证。这让人们更加困惑。如果您看到＆＃34; OAuth身份验证＆＃34; （不是＆＃34; OAuth授权＆＃34;），它是使用OAuth进行身份验证的解决方案。
理想的OAuth服务器实现明确区分了授权和身份验证。这样的实现仅需要最终用户的唯一标识符来发布访问令牌，但根本不需要（处理）ID和密码。这种实现并不关心如何确定唯一标识符。换句话说，它并不关心最终用户的身份验证方式。它只需要一个由最终用户身份验证确定的唯一标识符。
很难设计和实现这样一个理想的OAuth服务器，但它是可行的并且至少存在一个商业实现。
如果您的OAuth服务器根本不关心最终用户的身份验证方式（=如果您的OAuth服务器明确将授权与身份验证分开），您可以更灵活地设计整个系统，并且您可以按照自己的意愿行事。