如何为移动应用程序设计安全API /身份validation以访问服务?

我想提供我的webapp的一些function用于其他应用程序(我主要考虑智能手机,因为它们提供更多function,例如GPS,相机,……)。

从目前为止我遇到的其他API(例如GoogleMaps)来看,第三方开发人员会在我的网站上注册自己,他获得了一个API密钥(一些随机的UUID),他必须用它来validation他的请求。我的网站。 到现在为止还挺好…

是否有机制保护移动应用程序的最终用户免受恶意应用程序的攻击? 例如,第三方开发人员可以构建应用程序并从最终用户捕获所有用户名/密码,这样他就可以使用useraccount做坏事。 (例如,我可以构建一个Twitter应用程序,捕获所有用户名/密码,然后删除所有的推文,发布新的,…)是否有可能阻止这种情况? AFAIK你可以在网上使用oauth,这样我的网站登录框就会出现在另一个网站上并询问他们的用户名/密码,这样它就不会显示给第三方网站。 是否可以为智能手机应用程序实施安全身份validation? 你会怎么做?

对于Android和iPhone,您可以毫无问题地使用OAuth,到目前为止,我认为这是最好的方法。

这两种智能手机types的流程与Web应用程序相同,因为两种操作系统都可以让您从应用程序启动Web浏览器并将用户重定向到Web提供程序,这样他就可以授权您的请求(令牌),然后浏览器可以通过适当的回调URI将您的用户返回到应用程序。 我没有为手机实现oauth,但我从朋友那里听说有可能并且移动浏览器可以使用一些特殊的URI将用户重定向回你的app,例如scheme://app/parameters

以下是android: link的内容

有两个oauth用例:2腿和3腿

2-legged是您想要保护API的时候,因此只能从经过身份validation的消费者应用程序中调用它。 这是一种流行的方案,存在于AFAIK年代 – 消费者使用消费者共享密钥签署每个请求,并且提供者(您的API)也签署请求以查看签名是否匹配。 通过这种方式,您可以判断该使用者的API使用情况是否正常。

3-legged oauth包括消费者第三方应用程序的最终用户。 它非常适合,如果您想像两条腿一样再次保护您的API,因为请求仍然是签名的,但您的API也可以受最终用户的许可保护。 API的提供者发布令牌并将其提供给消费者应用程序(第三方应用程序)。 然后,此应用程序在本地保存令牌,并将用户重定向到Provider以授权令牌。 当用户授权它时,提供者将用户发送回消费者应用程序,然后消费者可以对您的API进行经过身份validation(签名)和授权(由用户 – 第三方)的请求。

一旦你阅读它的工作方式,协议就不是很复杂,并且非常灵活 – 你可以根据自己的需要扩展它。 我强烈建议它用于保护API,尤其是在访问API时需要用户权限的情况下。

这是一个关于oauth的非常好的网站: http : //hueniverse.com/oauth/

– – 加上 – –

消费者应用程序中的共享密钥存储存在一些安全隐患 – 在您的情况下是移动电话应用程序。

如果某人打开您的程序并反汇编代码并提取共享密钥,那么他可以创建将成功validation提供程序API的应用程序。 但是,如果需要用户授权(3条腿),这不是一个非常大的问题,因为仍然会要求用户授予这个错误的应用程序 – 现在由用户做出正确的选择。 除此之外 – 虚假应用程序将无法窃取用户的凭据,因为使用oauth,用户凭据仅在提供商的站点上输入。

关于你的第二个问题:

oauth的好处是:

  1. 当第三方访问敏感API时,可以要求用户获得许可;

  2. 用户永远不会在第三方应用程序中输入他的凭据。 每个第三方应用程序都是不受信任的,并且是潜在的攻击媒介。

例如,如果您是gmail – API的提供者并且您向第三方应用程序开发人员提供Web服务方法login(user, pass) ,那么他们可以在他们的应用程序中登录屏幕并登录用户。 但是在此过程中,他们的第三方应用程序会在将用户凭据发送到Gmail之前直接接收用户凭 我绝不会使用这样的应用程序。 问题在于,大多数人并不熟悉(特别是非技术人员)这种应用程序使用的后果,并且人们制作应用程序仍在利用这种旧的和不安全的做事方式。 但是,随着越来越多的人参与实施某些安全协议(如oauth(或类似)),人们将熟悉这种流程,并且会对这种侵入性的第三方应用程序产生更多的怀疑。

我说是侵入性的,因为想象一下下面的场景:

您可以在保加利亚或阿尔巴尼亚等非发达国家/地区制作付款API。 对于企业来说,这是一个非常好的机会,因为信用卡根本不是这些地方的常用付款方式。

此提供程序API受外露Web服务方法登录(用户,传递)的保护。 在第三方应用程序使用此方法与用户凭据(它已经采取)后,它可以访问charge(user, amount)方法。 然后,它可以使用它想要的任何参数调用此API方法,并向用户收取one hundred thousand million pessos :D

用户甚至不会知道。 此外,您无法通过权限分离API方法调用 – 用户同意的内容和不同意的内容。

其他缺点是用户在许多地方使用一个密码 – 这样第三方应用程序就可以访问用户可能使用相同密码的另一个服务。