我已经实施了OAuth 1.0a提供程序，并且使用标准的3-legged身份验证，可以成功对其进行身份验证的OAuth客户端。
OAuth保护我服务器上的REST API，并且我有一个消费它的移动应用程序。
在我的移动应用程序中，我有一些功能（端点），即使在最终用户登录其私人帐户之前也可以访问。 有些用户甚至可能只想在不创建帐户的情况下使用公共功能。
我想用OAuth保护“公共”和“私有用户”端点。
因此我认为要走的路是以下列方式使用OAuth（但我可能错了......非常错误。）
首次启动应用程序后，移动应用程序将首先执行双方式身份验证。这样，移动应用程序将获得“双腿”令牌。移动应用将使用此令牌访问公共端点。
当用户请求登录应用程序时（以及如果），移动应用程序将执行3条腿身份验证并获得“3条腿令牌”。从现在开始，应用程序将忘记之前的2条腿令牌，并使用3条腿令牌 访问公共和私人端点。
1）第一个问题。那有意义吗？还有另一种好办法吗？
现在我的问题是：我怎么能（服务器提供商）知道移动应用程序是否想要使用2-legged进行身份验证？我想，作为提供者，我需要知道是否要将客户端重定向到登录 用户填写的表格（在三条腿的情况下）或我将只发出一个已经授权的请求令牌（在两条腿的情况下），以便可以交换一个访问令牌（如3 -legged）。
我这样做的想法是为客户提供2个消费者密钥：一个在他们想要双腿时使用，一个在他们想要三条腿时使用。我，作为提供者，我将根据收到的消费者密钥知道要提供哪种流量。
2）第二（和最后一个问题）。这是明智的吗？有没有更好的方法来实现它？
我看到人们通过仅允许客户端（消费者）发送空访问令牌来实现两条腿。是这样的，而不是吗？
感谢。
答案 0 :(得分：7)
OAuth旨在管理第三方应用程序对REST API的访问。 例如。其他一些公司开发了一款将使用您的API的应用程序。并且您不希望您的客户向第三方提供这些服务的密码。在这种情况下，OAuth就是解决方案。如果没有第三方应用程序，则不需要OAuth。
如果您有单一服务，只有您的应用程序使用它，那么您不需要实施任何OAuth。您需要创建通常的用户/密码登录（可能是正确的检查）机制。
使用HTTPS足以保护端点交互。如果您想在移动应用程序或其他一些REST消费者上保护商店内容，那么您必须在保存之前加密它。
更新： 如果你想保护“终点”，那么三足OAuth就是解决方案。两脚解决方案需要将第三方应用+您的OAuth应用（或lib）安装到用户设备。否则，用户可能会被类似的UI伪装，只需提供一些第三方用户和密码。