创建移动应用程序的API - 身份验证和授权 [英] Creating an API for mobile applications - Authentication and Authorization

问题描述

我在找创建我的应用程序（REST）API。初始/主要目的将是通过移动应用（iPhone，Android的，塞班等）的消费。我一直在寻找到身份验证和授权基于Web的API不同的机制（通过学习其他实现）。我有我的头上缠大部分的基本概念，但在一些地区现在还在找工作的指导。我想做的最后一件事是推倒重来，但我没有找到任何标准的解决方案，适合我的标准（不过我的标准我被误导可以随意批评说为好）。此外，我希望API成为所有平台/应用中消费它一样的。

I'm looking to create a (REST) API for my application. The initial/primary purpose will be for consumption by mobile apps (iPhone, Android, Symbian, etc). I've been looking into different mechanisms for authentication and authorization for web-based APIs (by studying other implementations). I've got my head wrapped around most of the fundamental concepts but am still looking for guidance in a few areas. The last thing I want to do is reinvent the wheel, but I'm not finding any standard solutions that fits my criteria (however my criteria my be misguided so feel free to critique that as well). Additionally, I want the API to be the same for all platforms/applications consuming it.

我会继续前进，扔掉我反对的OAuth，因为我知道这将有可能提供的第一个解决方案。对于移动应用（或更具体地说非W​​eb应用程序），它只是似乎是错误的离开应用程序（去一个网络浏览器）的认证。此外，也没有办法（我知道的），用于浏览器的回调返回到应用程序（特别是跨平台）。我知道有几个是做应用的，但它只是觉得不妥，并给出了应用UX休息。

I'll go ahead and throw out my objection to oAuth since I know that will likely be the first solution offered. For mobile applications (or more specifically non-web applications), it just seems wrong to leave the application (to go to a web-browser) for the authentication. Additionally, there is no way (I am aware of) for the browser to return the callback to the application (especially cross-platform). I know a couple of apps that do that, but it just feels wrong and gives a break in the application UX.

1. 用户输入用户名/密码到应用程序。


2. 每个API调用被调用的应用程序标识。


3. 开销保持在最低水平，并在auth方面是直观的开发者。


4. 的机制是安全的同时为最终用户（他们的登录凭据不暴露）以及开发者（他们的应用程序凭据不暴露）。


5. 如果可能的话，不需要HTTPS（绝不是一个硬性要求）。

这是外部开发者将要求API帐户。他们将收到apikey和apisecret。每个请求都需要以最低的三个参数。

My Current Thoughts on Implementation

An external developer will request an API account. They will receive an apikey and apisecret. Every request will require at minimum three parameters.

• apikey - 在regisration给开发商


• 时间戳 - 双打作为唯一标识符为每个消息对于一个给定apikey


• 哈希 - 时间戳+的apisecret的哈希值

，则需要apikey标识应用程序发出请求。时间戳同样地起作用，所述oauth_nonce并避免/缓解重放攻击。哈希确保这一要求实际上是从给定的apikey的所有者发行。

The apikey is required to identify the application issuing the request. The timestamp acts similarly to the oauth_nonce and avoids/mitigates replay attacks. The hash ensures that request was actually issued from the owner of the given apikey.

有关身份验证的请求（那些在用户的代表做），我还是用的access_token路线或用户名和密码哈希组合会之间犹豫不决。无论哪种方式，在一些点上的用户名/密码组合是必需的。所以，当它，将使用的几条信息（apikey，apisecret，时间戳）+密码的哈希。 我很乐意在这方面的反馈意见。的通知你，他们就必须首先散列密码，因为我不在我的系统中存储​​的密码散列没有

For authenticated requests (ones done on the behalf of a user), I'm still undecided between going with an access_token route or a username and password hash combo. Either way, at some point a username/password combo will be required. So when it does, a hash of several pieces of information (apikey, apisecret, timestamp) + the password would be used. I'd love feedback on this aspect. FYI, they would have to hash the password first, since I don't store the passwords in my system without hashing.

仅供参考，这不是如何建立/结构一般只如何在应用程序中处理从单纯的认证和授权的API请求。

FYI, this isn't a request for how to build/structure the API in general only how to handle the authentication and authorization from solely within an application.

有关的API，只需要一个apikey作为请求的一部分，你怎么了prevent有人比能够看到apikey（因为在明文发送），并提出过高的要求，以推动他们的apikey所有者其他超过使用限制？也许我只是在想这一点，但不应该有东西来验证请求，验证到apikey主人？就我而言，那是apisecret的目的，这是从来没有显示/传输而不被散列。

For APIs that only require an apikey as part of the request, how do you prevent someone other than the apikey owner from being able to see the apikey (since sent in the clear) and make excessive requests to push them over usage limits? Maybe I'm just over thinking this, but shouldn't there be something to authenticate that a request was verified to the apikey owner? In my case, that was the purpose of the apisecret, it is never shown/transmitted without being hashed.

哈希说到，有什么关于MD5 VS HMAC-SHA1？是否真的重要，当所有的值都（即apisecret）？

Speaking of hashes, what about md5 vs hmac-sha1? Does it really matter when all of the values are hashed with with sufficiently long data (ie. apisecret)?

我一直previously考虑增加每用户/行盐我的用户密码哈希。如果我这样做，应用程序怎么可能能够在不知道使用的盐来创建一个匹配的哈希？

I had been previously considering adding a per user/row salt to my users password hash. If I were to do that, how could the application be able to create a matching hash without knowing the salt used?

推荐答案

我想在我的项目做的这个登录部分的方法是：

The way I'm thinking about doing the login part of this in my projects is:

1. 登录前用户请求 login_token 从服务器。这些都是产生并存储在请求的服务器上，并可能有一个有限的寿命。

1. before login the user requests a login_token from the server. These are generated and stored on the server on request, and probably have a limited lifetime.

登录该应用程序计算用户密码的哈希值，然后散列与 login_token 来得到一个值，然后他们同时返回<$密码C $ C> login_token 和联合混杂。

to login the application calculates the hash of the users password, then hashes the password with the login_token to get a value, they then return both the login_token and the combined hash.

服务器检查 login_token 是一个，它已经产生，从它的有效的列表中删除 login_token 秒。然后，服务器结合了其存储在用户的 login_token 密码散列，并确保其提交的合并令牌相匹配。如果匹配已认证用户。

The server checks the login_token is one that it has generated, removing it from its list of valid login_tokens. The server then combines its stored hash of the user's password with the login_token and ensures that it matches the submitted combined token. If it matches you have authenticated your user.

的这种方法的好处是，你永远不会存储用户的密码在服务器上，密码是永远不会阻碍地通过，密码哈希仅在帐户创建清晰的传递（虽然可能有办法解决这个），和应该从重放攻击是安全的 login_token 从DB上使用的删除。

Advantages of this are that you never store the user's password on the server, the password is never passed in the clear, the password hash is only passed in the clear on account creation (though there may be ways around this), and it should be safe from replay attacks as the login_token is removed from the DB on use.

这篇关于创建移动应用程序的API - 身份验证和授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！