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