“主要”网站/应用的OAuth例外

我已经开始考虑OAuth和整个重定向以授权概念

让第三方应用程序这样做是有道理的，但是公司的“实际”网站或应用程序呢

例如，Facebook网站/应用程序不会强迫您通过重定向流登录，即使它们可能在后台使用OAuth API

从OAuth的角度来看，似乎需要为这些类型的消费者制定例外。也就是说，只有少数几个应用程序基本上是自动授权的

---

这有意义吗？还是我遗漏了什么？

我不确定我是否正确理解了您的问题，但基本上，的主要目标是允许第三方应用程序访问资源所有者（即最终用户受保护的资源），而无需将资源所有者的凭据ID和密码传递给第三方应用程序

从Facebook服务器的角度来看，Facebook官方网站和应用程序不是第三方应用程序。也就是说，所有的实体服务器、应用程序和用户都属于Facebook。因此，Facebook服务器和Facebook官方应用程序不必使用OAuth 2.0。他们可以用自己喜欢的特殊、习惯和神秘的方式进行交流

同样，从Photobucket服务器的角度来看，官方Photobucket应用程序不是第三方应用程序。因此，允许应用程序通过应用程序的UI组件直接接受最终用户的凭据。另一方面，从PhotoFolio的观点来看，Photobucket应用程序是第三方应用程序。因为PhotoFolio想让Photbucket应用程序访问PhotoFolio服务，但不想让Photobucket应用程序收集PhotoFolio的最终用户凭据，所以PhotoFolio要求Photobucket应用程序使用OAuth 2.0

---

在OAuth 2.0流中，第三方应用程序无法知道最终用户的凭据。这就是重点。有资格了解最终用户凭据的非第三方应用程序不必使用OAuth 2.0。

Facebook实现OAuth 2.0的某些部分是不正确的。至少，Facebook处理重定向uri参数和范围参数的方式与RFC6749OAuth2.0不同。所以，在关于OAuth2.0的一般性讨论中不应提及Facebook的实现。几乎抓住了我在这里询问的确切体验。。。photobucket应用程序本身不会重定向您以授权任何内容。当您登录时，用户名和密码将直接在应用程序中运行。但是如果你看PhotoFolio，一个PB第三方消费者，你会被重定向到身份验证/授权。这个问题与OAuth的一般用法有关。我想说的是，人们希望重用一个api，而不是仅仅为他们自己的应用程序创建一个完全独立的api，所以很可能在如何利用现有的oauth api进行此类应用程序方面存在一些黑客/定制。很抱歉，oauth 1.0和oauth 2.0是非常不同的。听起来您将能够从OAuth 2.0 RFC 6749的资源所有者密码凭证授权中获得见解。在流中，不执行重定向，客户端应用程序直接访问令牌端点，而不访问授权端点。令牌端点接受用户名和密码请求参数。这听起来非常有用，我来看看！