如何为移动应用程序设计安全的 API/身份验证以访问服务? [英] How can I design a secure API/Authentication for mobile apps to access a service?

查看:18
本文介绍了如何为移动应用程序设计安全的 API/身份验证以访问服务?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想提供我的 web 应用程序的一些功能,以便在其他应用程序中使用(我主要考虑智能手机,因为它们提供了更多功能,例如 GPS、相机等).

到目前为止我在其他 API 方面遇到的情况,例如GoogleMaps 是第 3 方开发人员会在我的网站上注册自己,他获得一个 API 密钥(一些随机的 UUID)并且他必须使用它来验证他对我网站的请求.到目前为止一切顺利...

是否有保护移动应用最终用户免受恶意应用侵害的机制?例如.第三方开发人员可以构建一个应用程序并从最终用户那里捕获所有用户名/密码,以便他可以使用用户帐户做坏事.(例如,我可以构建一个 twitter 应用程序,捕获所有用户名/密码,然后删除他们所有的推文,发布新推文,......)有没有可能阻止这种情况?AFAIK 你可以在网络上使用 oauth,这样 my 网站登录框就会出现在另一个网站上,并要求他们输入用户名/密码,这样它就不会显示在 3rd 方网站上.是否可以为智能手机应用程序实施安全身份验证?你会怎么做?

解决方案

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

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

这里有一些关于 android 的内容:link

有两种 oauth 用例:2-legged 和 3-legged

2-legged 是当您想要保护您的 API 时,以便它只能从经过身份验证的消费者应用程序调用.这是 AFAIK 时代就存在的一种流行方案 - 消费者使用消费者共享密钥对每个请求进行签名,而提供者(您的 API)也对请求进行签名以查看签名是否匹配.通过这种方式,您可以判断 API 使用是否适合该消费者.

3-legged oauth 包括消费者 3rd 方应用的最终用户.它非常适合,如果你想像 2-legged 一样再次保护你的 API,因为请求仍然是签名的,而且你的 API 可以通过最终用户的许可来保护.API 的提供者发布令牌并将其提供给消费者应用程序(第 3 方应用程序).然后此应用程序将令牌保存在本地并将用户重定向到 Provider 以获取令牌授权.当用户授权时,提供者将用户发送回消费者应用程序,然后消费者可以向您的 API 发出经过身份验证(签名)和授权(由用户 - 第三条腿)的请求.

一旦您阅读了它的工作原理,该协议就不是很复杂,并且非常灵活 - 您可以根据自己的需要扩展它.我强烈推荐它来保护 API,尤其是在访问 API 需要用户许可的情况下.

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

--- 添加 ---

消费者应用程序中的共享密钥存储存在一些安全隐患 - 在您的案例中是手机应用程序.

如果有人打开你的程序并反汇编代码并提取共享密钥,那么他可以制作应用程序,该应用程序将成功通过提供者 API 进行身份验证.然而,如果需要用户授权(3 条腿),这不是一个非常大的问题,因为仍然会要求用户授予此虚假应用程序的权限 - 现在由用户做出正确的选择.除此之外 - 虚假应用将无法窃取用户的凭据,因为使用 oauth,用户凭据只能在提供商的站点上输入.

I want to offer some functions of my webapp to be used in other apps (I'm thinking mainly about smartphones, since they offer more capabilities e.g. GPS, Camera,..).

From what I have encountered myself so far in terms of other APIs e.g. GoogleMaps, is that a 3rd party developer would register himself at my site, he gets an API key (some random UUID) and he has to use it to authenticate his requests against my website. So far so good...

Is there a mechanism to protect the end user of a mobile app from malicious apps? E.g. a 3rd party developer could build an app and capture all username/passwords from the end user, so that he can do bad stuff with the useraccount. (E.g. I could build a twitter app, capture all the usernames/passwords and then delete all their tweets, post new ones,..) Is there a possibility to prevent this? AFAIK you could use oauth on the web so that my website login box would appear on another site and ask them for their username/password, so that it isn't shown to the 3rd party site. Is it possible to implement a secure authentication for smartphone apps? How would you do it?

解决方案

For Android and iPhone you can use OAuth without problems, and so far I think this is the best way to be done.

The flow for these two smartphone types is the same like in web applications, because both OS give you the possibility to start web browser from your application and redirect the user to web provider, so he can authorize your request (token), and then the browser can return your user to the application via proper callback URI. I haven't implemented oauth for mobile phones, but I've heard from a friend that it's possible and that the mobile browser can redirect the user back to your app with some special URI, like scheme://app/parameters.

Here is something for this with android: link

There are two oauth use cases: 2-legged and 3-legged

2-legged is when you want to protect your API, so that it can be called only from authenticated consumer applications. This is a popular scheme that exists from ages AFAIK - the consumer signs every request with a consumer shared key, and the provider (your API), signs the request also to see if the signature match. This way you can tell if API usage is ok for that consumer.

3-legged oauth includes the end-user of the consumer 3rd party app. It is very suitable, if you want to protect your API again like in 2-legged, because requests are still signed, but also your API can be protected by the end-user's permission. The provider of the API issues a token and gives it to the consumer application (3rd party app). Then this app saves the token locally and redirects the user to Provider for authorization of the token. When the user authorizes it, the provider sends back the user to the consumer application and then consumer can make authenticated (signed) and authorized (by the user - 3rd leg) requests to your API.

The protocol is not very complicated once you read how it works, and is very flexible - you can extend it to your needs however you like. I would highly recommend it for protecting APIs, especially if user permission is required for access to the APIs.

This is a very good site to read about oauth: http://hueniverse.com/oauth/

--- ADD ON ---

There is some security implications regarding shared key storage in the consumer application - mobile phone app in your case.

If somebody open your program and disassemble the code and extract the shared key, then he can make application which will authenticate successfully to the provider API. However this is not a very big concern if user authorization is required (3-legged), because the user will still be asked to give permission to this false application - and now it's up to the user to make the proper choice. And besides that - the false app will not be able to steal user's credentials, because with oauth, user credentials are entered only at the provider's site.

这篇关于如何为移动应用程序设计安全的 API/身份验证以访问服务?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆