为移动应用程序创建一个API
概观
我正在为我的应用程序创建一个（REST）API。 初始/主要目的是供移动应用程序（iPhone，Android，Symbian等）使用。 我一直在研究基于Web的API的认证和授权的不同机制（通过研究其他实现）。 我的脑袋缠绕了大部分基本概念，但仍在寻找少数领域的指导。 我想要做的最后一件事是重新发明轮子，但我没有找到符合我的标准的任何标准解决方案（但是我的标准被误导了，因此可以随意批评）。 另外，我希望API对于所有使用它的平台/应用程序都是相同的。
OAuth的
我会继续向oAuth抛出异议，因为我知道这可能是第一个解决方案。 对于移动应用程序（或更具体的非Web应用程序），将应用程序（转到Web浏览器）用于身份验证似乎是错误的。 此外，浏览器无法（我知道）将回调函数返回给应用程序（尤其是跨平台）。 我知道有几个应用程序可以做到这一点，但它只是感觉不对，并在应用程序用户体验中突破。
要求
我当前的实施思路
外部开发者将要求一个API帐户。 他们将获得apikey和apisecret。 每个请求至少需要三个参数。
apikey需要识别发出请求的应用程序。 时间戳与oauth_nonce类似，并避免/减轻重放攻击。 哈希确保请求实际上是从给定apikey的所有者发出的。
对于经过身份验证的请求（代表用户完成的请求），我仍然未确定要使用access_token路由还是用户名和密码哈希组合。 无论哪种方式，都需要用户名/密码组合。 所以当它发生时，会使用几条信息（apikey，apisecret，timestamp）和密码。 我喜欢这方面的反馈。 仅供参考，他们将不得不首先散列密码，因为我没有在没有散列的情况下将密码存储在我的系统中。
结论
仅供参考，这不是对如何构建/构建API的一般请求，而仅仅是如何处理来自应用程序中的验证和授权。
随机思考/奖金问题
对于仅需要apikey作为请求一部分的API，您如何防止除apikey所有者之外的人能够看到apikey（自从发送明文之后）并发出过多请求来推动他们超出使用限制？ 也许我只是在想这个问题，但是不应该有任何事情来验证apikey所有者的请求是否已被验证？ 就我而言，这是apisecret的目的，它不会被显示/传输而不会被散列。
说到哈希，md5 vs hmac-sha1呢？ 当所有的值与足够长的数据（即apisecret）进行散列时，它是否真的很重要？
我以前一直在考虑将每个用户/行盐添加到我的用户密码哈希中。 如果我这样做，那么应用程序如何能够在不知道使用的盐的情况下创建匹配的散列？
我想在我的项目中做这个登录部分的方式是：
在登录之前，用户向服务器请求login_token 。 这些都是根据请求生成并存储在服务器上的，并且可能具有有限的生命周期。
登录应用程序计算用户密码的散列值，然后使用login_token散列密码以获取值，然后返回login_token和组合散列值。
服务器检查login_token是否已经生成，并将其从有效的login_token列表中login_token 。 然后，服务器将其存储的用户密码散列与login_token并确保它与提交的组合令牌相匹配。 如果匹配，则表示已通过身份验证。
这样做的好处是，你永远不会在服务器上存储用户的密码，密码永远不会以明文形式传递，密码哈希只会在帐户创建时被明确地传递（虽然可能有解决方法），它应该是因为login_token从使用中的数据库中删除，所以login_token重放攻击。
这是一个很大的问题，我想很多人没有设法读完所有的方式:)
我对Web服务身份验证的经验是，人们通常过度工程，并且问题与您在网页上遇到的问题相同。 可能非常简单的选项包括用于登录步骤的https，返回令牌，要求它包含在未来的请求中。 您也可以使用http基本身份验证，并只传递头中的内容。 为了增加安全性，请经常旋转/过期令牌，检查请求是否来自同一个IP块（这可能会在移动用户在单元格之间移动时变得混乱），并与API密钥或类似内容结合使用。 或者，在对用户进行身份验证之前，执行oauth的“请求密钥”步骤（有人在之前的回答中已经提出了这一点，这是一个好主意），并将其用作生成访问令牌所需的密钥。
我还没有使用过的另一种方法，但是我听说很多关于oAuth的设备友好型替代方法是xAuth。 看看它，如果你使用它，那么我会非常有兴趣听到你的印象。
对于散列，sha1稍微好一些，但不要挂上电话 - 无论设备可以轻松（并且快速地在性能意义上）执行都可能很好。
希望有所帮助，祝你好运:)
Twitter通过支持他们称为xAuth的变体来解决oAuth中的外部应用程序问题。 不幸的是，这个名字已经有很多其他的方案，因此可能会让人困惑。
该协议是oAuth，除了它跳过了请求令牌阶段并且在收到用户名和密码后立即发出访问令牌对。 （从这里的步骤E开始。）这个初始请求和响应必须是安全的 - 它以明文形式发送用户名和密码并接收访问令牌和秘密令牌。 一旦配置了访问令牌对，初始令牌交换是通过oAuth模型还是xAuth模型与客户端和服务器在会话的其余部分都不相关。 这样做的好处是您可以利用现有的oAuth基础架构，并具有与移动/ Web /桌面应用程序几乎相同的实现。 主要的缺点是应用程序被授予访问客户端的用户名和密码的权限，但看起来像您的需求使用这种方法。
无论如何，我想在此同意你的直觉和其他几位答复者的直觉：不要试图从头开始构建新的东西。 安全协议可以很容易开始，但总是很难做到，而且越复杂，它们越可能成为第三方开发人员能够实施的对手。 您的假设协议与o（x）Auth - api_key / api_secret，nonce，sha1哈希非常相似 - 但是您不需要使用众多现有库中的一个，您的开发人员将需要推出自己的库。
链接地址: http://www.djcxy.com/p/3757.html上一篇: Creating an API for mobile applications
下一篇: How to use java.net.URLConnection to fire and handle HTTP requests