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

问题描述

我希望为我的应用程序创建一个 (REST) API.最初/主要目的是供移动应用程序(iPhone、Android、Symbian 等)使用.我一直在研究基于 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 的反对意见，因为我知道这可能是提供的第一个解决方案.对于移动应用程序(或更具体地说是非 Web 应用程序)，让应用程序(转到 Web 浏览器)进行身份验证似乎是错误的.此外，浏览器无法(我知道)将回调返回给应用程序(尤其是跨平台).我知道有几个应用可以做到这一点，但它只是感觉不对，并且会影响应用的用户体验.

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. 开销保持在最低水平，并且身份验证方面对开发人员来说很直观.
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 - 在注册时提供给开发人员
• 时间戳 - 对于给定的 apikey，作为每条消息的唯一标识符的两倍
• hash - 时间戳 + 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.

对于只需要 apikey 作为请求一部分的 API，您如何防止 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 和 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)?

我之前一直在考虑向我的用户密码哈希添加每个用户/行的 salt.如果我这样做，应用程序如何能够在不知道使用的盐的情况下创建匹配的哈希?

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 对密码进行哈希运算得到一个值，然后返回两个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 在使用时已从数据库中删除，因此它应该不会受到重放攻击.

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屋！