我反复阅读过，OpenID比OAuth（用于授权）更适合身份验证，包括SO上的其他几个帖子 .
案件似乎也经常被引用的文章中提到 .
但是，我有点不清楚为什么我应该支持OpenID进行身份验证，而不是一个诚实的OAuth提供商（例如Twitter或Facebook OAuth 2.0） . 其他SO帖子我解释了为什么人们不能使用OAuth进行身份验证 .
以下是我能提出的原因以及我（可能是误入歧途）的回复：
-
OAuth真的用于授权 . 让用户使用OAuth进行身份验证可以为消费者提供比他们需要的更多权限 .
-
响应：这通常是正确的，但在细粒度OAuth（例如Facebook提供）的情况下，它允许我仅请求非常小的权限 . 事实上，Facebook等许多网站都提供OAuth，但不提供OpenID，可能是因为他们对授权消费者比认证客户更感兴趣 . 如果我想为客户提供更多身份验证选项，OAuth似乎会向我提供这些选项 .
-
OAuth会话往往寿命更长
-
响应：如果我自己进行会话管理，甚至可以在我完成对用户的身份验证后立即删除OAuth令牌，则无关紧要 .
与使用大规模OAuth提供程序进行身份验证相比，OpenID提供了哪些身份验证优势？
2 回答
使用OAuth进行身份验证的根本挑战是，您需要根据对给定资源的访问权限来假设一个身份 . 在某些情况下，这可能是一个有效的假设，但OAuth并不能保证 . 如果您对用于身份验证的资源的访问权限委托给另一方，并且您假设基于对该资源的访问权限的身份，那么这是一个漏洞，可以允许冒名顶替者代表其他订阅者进行身份验证 . 这与OAuth提供商的诚实或缺乏无关，以及与以未设计的方式使用的工具有关的一切 .
对于Facebook，OAuth可以支持仅基于能够授权应用程序的订阅者进行身份验证的身份验证：如果您获得访问个人配置文件的授权，则表示订阅者必须已通过Facebook身份验证 . 看来这是一个受支持的用例 . 但是，如果Facebook稍后允许其他应用程序或用户代表其订户授权资源，则该保证将丢失 .
最终，要使用OAuth进行身份验证，您需要做出很多假设 . 您需要假设您正在进行身份验证的用户，并且只有该用户才有权委派给定资源;您必须假设您收到的请求数据足以绑定到已知身份;你必须假设认证机制足以对第三方进行身份验证（如果文件不敏感并且可以授予匿名访问，该怎么办？）;你必须假设这些品质随着时间的推移而持续存在 . OpenID专门为此而构建; OAuth不是 .
你能安全地做出这些假设吗？在Facebook的情况下，可能;它们似乎是文档化和支持的用例（我不熟悉特定的API） . 但一般来说，它不是受支持的OAuth用例 .
您需要问自己的主要问题是，您是否提前知道要支持哪些提供商 . 如果您希望允许用户使用任何提供商（使用OpenID支持，如Google，Yahoo，AOL等），您应该使用OpenID . 但是，如果您知道大多数用户想要使用Twitter，Facebook或其他一些流行的OAuth提供商，请使用它们 .
技术术语是OAuth提供委托身份验证，而OpenID提供联合身份验证 . 现在，OAuth确实是授权协议而不是身份验证协议，但通过向您提供/我（Facebook）或/ account / verify_credentials（Twitter），这些提供商扩展了OAuth以用作身份验证协议 .
但是你不应该使用OpenID . 这是一个死的协议 .