REST API 授权 &身份验证(网络 + 移动) [英] REST API Authorization & Authentication (web + mobile)

问题描述

我已经阅读了有关 oAuth、Amazon REST API、HTTP Basic/Digest 等的内容，但无法将其全部归入单一部分".这可能是最接近的情况 - 为移动应用程序创建 API -身份验证和授权

I've read about oAuth, Amazon REST API, HTTP Basic/Digest and so on but can't get it all into "single piece". This is probably the closest situation - Creating an API for mobile applications - Authentication and Authorization

我想构建以 API 为中心的网站 - 服务.所以(一开始)我会在中心有一个 API，网站(PHP + MySQL)将通过 cURL、Android 和 连接>iPhone 通过他们的网络接口.所以 3 个主要客户端 - 3 个 API 密钥.任何其他开发人员也可以通过 API 接口进行开发，他们将获得自己的 API 密钥.API 操作将根据 userLevel 状态被接受/拒绝，如果我是管理员，我可以删除任何内容等，所有其他人只能操作他们的本地(帐户)数据.

I would like to built API-centric website - service. So (in the beginning) I would have an API in center and website (PHP + MySQL) would connect via cURL, Android and iPhone via their network interfaces. So 3 main clients - 3 API keys. And any other developer could also develop via API interface and they would get their own API key. API actions would be accepted/rejected based on userLevel status, if I'm an admin I can delete anything etc., all other can manipulate only their local (account) data.

首先，授权 - 我应该使用 oAuth + xAuth 还是我自己的某种实现(请参阅 http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/RESTAuthentication.html?r=9197)?据我了解，亚马逊服务用户是 == API 用户(拥有 API 密钥).在我的服务中，我需要将标准用户/帐户(在网站上注册的那个)和开发者帐户(应该拥有他们的 API 密钥)分开.

First, authorization - should I use oAuth + xAuth or my some-kind-of-my-own implemenation (see http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/RESTAuthentication.html?r=9197)? As I understand, on Amazon service user is == API user (have API key). On my service I need to separate standard users/account (the one who registered on the website) and Developer Accounts (who should have their API key).

所以我首先需要授权 API 密钥，然后验证用户本身.如果我使用亚马逊的方案来检查开发者的API密钥(授权他们的应用程序)，我应该使用哪个方案进行用户身份验证?

So I would firstly need to authorize the API key and then Authenticate the user itself. If I use Amazon's scheme to check developer's API keys (authorize their app), which sheme should I use for user authentication?

在(通过 HTTPS、HTTP Basic)发布我的用户名和密码之后，我了解到通过 api.example.org/auth 获取令牌，然后在每个以下请求.如果我同时登录 Android 和 网站，如何管理令牌?如果我仅在第一次请求时使用 SSL(传输用户名和密码时)，并且每隔一个使用 HTTP，那么中间人攻击呢?在这个例子中，这不是问题吗密码保护 REST 服务?

I read about getting a token via api.example.org/auth after (via HTTPS, HTTP Basic) posting my username and password and then forward it on every following request. How manage tokens if I'm logged in simultaneously on Android and a website? What about man-in-the-middle-attack if I'm using SSL only on first request (when username and password are transmitted) and just HTTP on every other? Isn't that a problem in this example Password protecting a REST service?

推荐答案

一如既往，保护密钥的最佳方法是不传输它.

As allways, the best way to protect a key is not to transmit it.

也就是说，我们通常使用一种方案，其中每个API 密钥"都有两部分:非机密 ID(例如 1234)和机密密钥(例如字节 [64]).

That said, we typically use a scheme, where every "API key" has two parts: A non-secret ID (e.g. 1234) and a secret key (e.g. byte[64]).

• 如果您提供 API 密钥，请将其存储(加盐和散列)服务的数据库.
• 如果您提供用户帐户(受密码保护)，请存储服务数据库中的密码(加盐和散列)

现在，当消费者第一次访问您的 API，要连接时，让他

Now when a consumer first accesses your API, to connect, have him

• 发送用户名"参数(john.doe"不是秘密)
• 发送APIkeyID"参数(1234"，非机密)

把他还给他

• 数据库中的盐(如果其中一个参数错误，只需返还一些可重复的盐 - 例如.sha1(用户名+notverysecret").
• 服务器的时间戳

消费者应该在会话期间存储盐以保持快速和流畅，并且他应该计算并保持客户端和服务器之间的时间偏移.

The consumer should store the salt for session duration to keep things fast and smooth, and he should calculate and keep the time offset between client and server.

消费者现在应该计算 API 密钥和密码的加盐哈希.通过这种方式，消费者拥有与数据库中存储的完全相同的密码和 API 密钥哈希值，但没有任何秘密通过网络传输.

The consumer should now calculate the salted hashes of API key and password. This way the consumer has the exact same hashes for password and API key, as what is stored in your database, but without anything seceret ever going over the wire.

现在，当消费者随后访问您的 API 时，让他做真正的工作

Now when a consumer subseqently accesses your API, to do real work, have him

• 发送用户名"参数(john.doe"不是秘密)
• 发送APIkeyID"参数(1234"，非机密)
• 发送RequestSalt"参数(字节[64]，随机，非秘密)
• 发送RequestTimestamp"参数(根据客户端时间和已知偏移量计算)
• 发送RequestToken"参数(hash(passwordhash+request_salt+request_timestamp+apikeyhash))

服务器不应接受超过过去 2 秒的时间戳，以使其免受重放攻击.

The server should not accept timestamps more than say 2 seconds in the past, to make this safe against a replay attack.

服务器现在可以计算与客户端相同的哈希值(passwordhash+request_salt+request_timestamp+apikeyhash)，并且可以肯定，

The server can now calculate the same hash(passwordhash+request_salt+request_timestamp+apikeyhash) as the client, and be sure, that

• 客户端知道 API 密钥，
• 客户端知道正确的密码

这篇关于REST API 授权 &身份验证(网络 + 移动)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！