Mat*_* Mc 10 authentication api oauth user-accounts web
我对OAuth相关主题有一些困惑,我希望有人可以帮助我清理它们:)在任何我不合适的地方随意纠正我.
所以,假设我的网络公司在不同的域上运行了许多网站:
假设这些是带有一些社交性的电子商务网站,因此存在具有各种存储数据点的用户帐户.所以我的公司(我们称之为ACME电子商务)已经为不同的客户创建并管理所有这些网站.
现在,我们决定为所有电子商务网站建立一个中央帐户是很方便的; 其好处包括通过允许客户使用现有帐户登录任何站点来减少摩擦,以及集中信息以提高营销准确性并减少与客户的过多沟通.输入OAuth!
据我所知,OAuth是一种身份验证和授权标准.身份验证是"登录",授权是"你可以进行这些API调用",简而言之,对吗？让我们从身份验证开始:
认证!
这里的想法是你去socks.com,当你通常登录时,有一个"使用ACME ID登录"按钮,以及"登录到Socks.com".你到处都可以看到:登录Facebook,登录谷歌等等.所以我们有"使用ACME ID登录".
当用户点击"使用ACME ID登录"时,socks.com直接从ACME的OAuth服务器请求并接收未经授权的请求令牌,然后将用户的浏览器重定向到ACME的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会做这样的事情; 他们"登录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,我们可以进行API调用ACME资源服务器,传递ACME ID的用户名,来获取客户的地址的数组,然后用它来填充网页.嘿,这是很好的服务!Cakes.com 由OAuth程序授权执行此类操作.
我有一切吗？
边缘案例!
上面带有中央OAuth服务器的电子商务网站的实现非常明确,但是有些"边缘情况"可能会以不同的方式实现:
1)没有分布式用户帐户
如果我想强制socks.com,boats.com和cakes.com的所有用户仅使用ACME ID登录,该怎么办？也许在每个站点都有一个"用户帐户",包括购买数据和地址数据等,带有相关的用户名,但没有密码,也没有实际的登录机制.一旦ACME ID被验证,会话就被标记为"登录".
或者,也许所有信息(如购买历史记录,地址和CC#)都会汇总到ACME资源端点中,而不会在卫星电子商务网站上存储有关客户的信息？那么,卫星基本上是奴隶,使用ACME OAuth作为远程数据库.然后,由于购买历史是集中的,您或多或少需要集中您的项目,然后它可能会归结为"什么不集中？" 和"为什么有单独的网站" - 除了他们需要分开.
那么,这有什么好处吗？
2)用于移动应用程序的UI-Less 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)访问多个站点的Central Auth
我们采取这种设置:ACME ID包含用户名,密码,电子邮件,信用卡和账单信息.Socks.com,boats.com和cakes.com有购买历史记录,以及关于这些人在这些网站上做过的与袜子相关,船相关或蛋糕相关(分别)的事情的社交信息.
现在我们想要创建一个使用ACME ID进行身份验证的移动应用程序,并且可以从ACME ID的Resource API(用于CC和计费数据)以及使用ACME ID进行身份验证的每个站点提取信息.通过这种方式,我们可以很好地融合袜子,船只和蛋糕,然后我们可以为客户收取费用!(你明白了.)
那么......怎么可能呢？
谢谢阅读!
OAuth 2.0 是一个授权规范，但不是身份验证规范。RFC 6749，3.1 。授权端点明确表示如下：
授权端点用于与资源所有者交互并获取授权。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录、会话cookie）超出了本规范的范围。
身份验证处理有关“谁是谁”的信息。授权处理有关“谁向谁授予什么权限”的信息。授权流程包含身份验证作为其第一步。这就是人们经常感到困惑的原因。
有许多库和服务使用 OAuth 2.0 进行身份验证。这让人们更加困惑。如果您看到“OAuth 身份验证”（而不是“OAuth 授权”），则这是使用 OAuth 进行身份验证的解决方案。
理想的 OAuth 服务器实现将授权与身份验证明确分开。这种实现仅需要最终用户的唯一标识符来颁发访问令牌，但根本不需要（处理）ID 和密码。这样的实现不关心如何确定唯一标识符。换句话说，它不关心最终用户如何进行身份验证。它只需要一个由最终用户身份验证确定的唯一标识符。
设计和实现这样一个理想的 OAuth 服务器很困难，但它是可行的，并且至少存在一种商业实现。
如果您的 OAuth 服务器根本不关心最终用户如何进行身份验证（= 如果您的 OAuth 服务器明确地将授权与身份验证分开），您可以更灵活地设计整个系统，并且可能可以做您想做的事情。
| 归档时间： |
|
| 查看次数： |
2268 次 |
| 最近记录： |