authentication - 与 OAuth 相比，OpenID OAuth 扩展有哪些优势？

Question

为什么建议使用OpenID OAuth Extension通过另一个基于 OAuth 的协议(protocol)？

发现似乎不是一项功能。尽管消费者只需要声明的标识符即可启动身份验证过程，但任何授权仍需要消费者知道访问 token URL、签名方法，并与提供者共享 key / secret 。

一个好处是有一种指定的方式来请求特定的授权，即身份验证请求的 openid.oauth.scope 参数。这样做的一个具体好处是身份验证 - 仅为消费者的利益，没有可验证的 token - 是免费定义的，并且可以执行而不必担心跟踪未完成的 token 或他们可能需要的资源。

是否有使用替代方法的示例来指定要请求的范围，也许是在 OpenID 发现中？或者这是否可以在 OAuth 流程之前通过某种 REST 导航有效地处理，在 OAuth 流程中，通过解释从众所周知的 URL 开始的超文本来发现特定于所需范围的多个请求 token URL 之一？

我正在研究具有多个授权范围的委托(delegate)身份验证和授权系统，其中范围与不同的交互相关。换句话说，消费者需要告诉提供者哪些范围应该呈现给用户以获得授权。

Answer 1

与标准 OAuth 相比，OpenID+OAuth 扩展实际上只有一个显着优势:

如果您需要对用户进行身份验证并访问用户的私有(private)数据，并且 OpenID 提供者恰好也是 OAuth 服务提供者(用户使用相同的身份验证保存他的私有(private)数据的服务)，那么扩展将帮助用户只有一个重定向到 OP+SP，而不是两个单独的重定向。对于用户来说，这是一个巨大的可用性胜利——如果他碰巧用他的 SP 进行身份验证。

支持扩展的风险是充分支持 OP 和 SP 不是同一实体的用户(你不想说你会支持扩展然后无意中将 OP 不是他们的 SP 的用户拒之门外) .

记住你真正需要知道的。如果您只想访问用户的私有(private)数据，但并不真正关心与您交互的用户是谁，请只使用 OAuth。例如，如果您只是下载他的照片以提供照片打印服务，或者如果您已经拥有该用户的非 OpenID 帐户，则用户没有理由通过 OpenID 放弃他的身份。