Jus*_*tin 15 rest restful-authentication oauth oauth-2.0
当用户帐户信息(用户ID,密码,角色等)将在我们自己的后端维护以及何时不与其他站点共享资源时,OAuth是否合理？或者分享使用OAuth的全部意义？
背景:
我正在开发企业SaaS产品,我们正在创建一个RESTful API供我们的前端应用程序使用.API的消费者将是我们开发的浏览器和本机智能手机(iOS和Android)应用程序.由于我们将支持多种客户端类型,因此创建我们所有客户端应用程序都可以使用的RESTful API是有意义的.
当然,我们需要保护这个RESTful API.我们正在考虑使用HTTPS/Basic Auth进行身份验证,但我们知道这种方法存在一些众所周知的缺点.
一些快速研究表明OAuth是强烈推荐的.但我发现OAuth的大部分内容都是在授权网站代表用户共享信息的背景下.
任何信息,如果最受欢迎.
小智 8
很好的问题,我们在API Craft上对此进行了很好的讨论:
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
这是我在那里发布的答案:
实际上,我认为这是OAuth的一个很好的用例.
首先,使用OAuth,您的移动应用可以在客户端上存储OAuth令牌,而不是用户的"真实"密码.因此,您可以通过获取OAuth令牌自动"登录用户",而无需在设备上存储实际密码.如果用户丢失了设备,或者某些设备遭到入侵,他们(或您)可以擦除OAuth令牌,而无需用户更改密码并吹走他们可能使用API执行的其他操作.Ajax风格的Web应用程序有类似的示例,但它更多地取决于您构建客户端的具体方式.
其次,OAuth令牌与唯一键相关联,该唯一键标识正在进行API调用的应用程序,并反过来标识构建应用程序的开发人员.这为您提供了一些选项,例如跟踪应用程序的使用情况,在不禁用整个API的情况下关闭可能已被入侵的应用程序,以及如果您想要打开对为您的API构建应用程序的第三方或合作伙伴的访问权限,您可以提供不同的级别对其他客户的服务.
第三,如果您告诉他们您从未在用户的移动设备上存储密码或将其藏匿在浏览器中的某个位置,您的IT安全人员会很高兴.
第四,您可以选择基于浏览器的移动应用程序登录.这意味着移动应用程序永远不会看到用户的密码,而且如果您想要实现双因素安全性或类似的东西,您可以在登录屏幕中执行此操作而无需更改移动应用程序.现在,缺点是用户看到弹出的浏览器窗口.这就是为什么OAuth为您提供了一些获取应用程序访问令牌的方法,因此您可以选择是否需要基于浏览器的登录或让用户直接在应用程序中输入密码.
第五,你怎么知道你的API只会被你自己的应用程序使用？如果您现在使用OAuth,那么稍后您将更容易进行转换.
| 归档时间： |
|
| 查看次数： |
5097 次 |
| 最近记录： |