为什么我应该使用OpenID进行身份验证而不是OAuth？

Question

我反复阅读过，OpenID比OAuth（授权版）更适合身份验证，包括SO上的其他几个帖子。

案件似乎也在经常被引用的this文章中提出。

但是，我对为什么我不太清楚我应该支持OpenID进行身份验证，而不是诚实的OAuth提供商（例如Twitter或Facebook OAuth 2.0）。我读过的其他SO帖子解释了不同的用例，我理解协议的设计目的之间的区别，但是它们没有解释为什么人们不能使用OAuth进行身份验证。

以下是我能提出的原因以及我的（可能是误导的）回复：

1. OAuth真的用于授权。让用户使用OAuth进行身份验证可以为消费者提供比他们需要的更多权限。
   • 回复：这通常是正确的，但在细粒度OAuth（例如Facebook提供）的情况下，它更加有限，这使我只能请求非常小的权限。事实上，Facebook等许多网站都提供OAuth，但不提供OpenID，可能是因为他们对授权消费者比认证客户更感兴趣。如果我想为客户提供更多身份验证选项，OAuth似乎会向我提供这些选项。
2. OAuth会话往往寿命更长
   • 回复：如果我是消费者意图对客户进行身份验证，则无关紧要;我会做自己的会话管理，甚至可以在我完成用户身份验证后立即删除OAuth令牌。

与使用大规模OAuth提供程序进行身份验证相比，OpenID提供了哪些身份验证优势？

Answer 1

您需要问自己的主要问题是，如果您提前知道要支持哪些提供商。如果您希望允许用户使用任何提供商（使用OpenID支持，如Google，Yahoo，AOL等），您应该使用OpenID。但是，如果您知道大多数用户想要使用Twitter，Facebook或其他受欢迎的OAuth提供商之一，请使用这些。

技术术语是OAuth提供委派身份验证，而OpenID提供联合身份验证。现在，OAuth确实是授权协议而不是身份验证协议，但通过向您提供/我（Facebook）或/ account / verify_credentials（Twitter），这些提供商扩展了OAuth以用作身份验证协议。

但是你不应该使用OpenID。这是一个死的协议。

Answer 2

使用OAuth进行身份验证的根本挑战是，您需要根据对给定资源的访问权限来假设一个身份。在某些情况下，这可能是一个有效的假设，但OAuth并不能保证。如果您对用于身份验证的资源的访问权限委托给另一方，并且您假设基于对该资源的访问权限的身份，那么这是一个漏洞，可以允许冒名顶替者在另一个订阅者身上进行身份验证。这与OAuth提供商的诚实或缺乏无关，以及与未按其设计方式使用的工具有关的一切。

对于Facebook，OAuth可以支持仅基于能够授权应用程序的订阅者进行身份验证的身份验证：如果您获得访问个人配置文件的授权，则表示订阅者必须已通过Facebook身份验证。看来这是一个受支持的用例。但是，如果Facebook稍后允许其他应用程序或用户代表其订阅者授权资源，则该保证将丢失。

最终，要使用OAuth进行身份验证，您需要做出很多假设。您需要假设您正在进行身份验证的用户，并且只有该用户才有权委派给定资源;您必须假设您收到的请求数据足以绑定到已知身份;你必须假设认证机制足以对第三方进行身份验证（如果文件不敏感并且可以授予匿名访问，该怎么办？）;你必须假设这些品质随着时间的推移而持续存在。 OpenID专门为此而构建; OAuth不是。

你能安全地做出这些假设吗？在Facebook的情况下，可能;它们似乎是文档化和支持的用例（我不熟悉特定的API）。但通常情况下，它不是受支持的OAuth用例。