为移动应用程序创建API-身份验证和授权
总览 我正在为我的应用程序创建一个（REST）API。最初/主要目的是供移动应用程序（iPhone，Android，Symbian等）使用。我一直在研究基于Web的API的身份验证和授权的不同机制（通过研究其他实现）。我已经把大部分基本概念都束之高阁，但仍在一些方面寻求指导。我想做的最后一件事是重新发明轮子，但是我没有找到任何适合我标准的标准解决方案（但是我的标准可能会被误导，因此也随时可以批评我）。另外，我希望所有使用它的平台/应用程序的API都相同。 oAuth 我会继续反对oAuth，因为我知道这可能是第一个提供的解决方案。对于移动应用程序（或更确切地说是非Web应用程序），离开应用程序（转到Web浏览器）进行身份验证似乎是错误的。另外，浏览器无法（我知道）将回调返回给应用程序（尤其是跨平台）。我知道有几个应用程序可以做到这一点，但是感觉不对，并中断了应用程序UX。 要求 用户在应用程序中输入用户名/密码。 每个API调用均由调用应用程序标识。 开销降至最低，并且对于开发人员而言，auth方面很直观。 该机制对于最终用户（不公开其登录凭据）和开发人员（不公开其应用程序凭据）都是安全的。 如果可能，则不需要https（绝不是硬要求）。 我当前的实施思想 外部开发人员将请求一个API帐户。他们将获得一个apikey和apisecret。每个请求至少需要三个参数。 apikey-在注册时提供给开发人员 时间戳-兼用作给定apikey的每个消息的唯一标识符 hash-时间戳+ apisecret的哈希 需要apikey来标识发出请求的应用程序。时间戳记的行为与oauth_nonce类似，并且避免/减轻了重播攻击。哈希确保请求实际上是从给定apikey的所有者发出的。 对于经过身份验证的请求（代表用户的请求），我仍然不确定要使用access_token路由还是使用用户名和密码哈希组合。无论哪种方式，在某个时候都将需要用户名/密码组合。因此，当这样做时，将使用多个信息（apikey，apisecret，时间戳）和密码的哈希。 我希望在这方面提供反馈。 仅供参考，他们必须先对密码进行哈希处理，因为我不会在不进行哈希处理的情况下将密码存储在系统中。 结论 仅供参考，这并不是要求通常如何构建/结构化API，而仅仅是要求如何仅从应用程序内部处理身份验证和授权。 随机想法/奖金问题 对于仅要求将apikey作为请求的一部分的API，如何防止apikey所有者以外的其他人看到apikey（因为是明文发送的），并提出过多的请求以使它们超过使用限制？也许我只是在考虑这个问题，但是不应该有什么东西可以验证对apikey所有者进行了验证的请求吗？在我的情况下，这是apisecret的目的，它不会被散列而不会显示/传输。 说到哈希，md5 vs hmac-sha1呢？当所有值都用足够长的数据（即apisecret）进行哈希处理时，真的重要吗？ 我以前一直在考虑向用户密码哈希添加每用户/行盐。如果要这样做，应用程序如何能够在不知道使用盐的情况下创建匹配的哈希？