blocks|key|231767|text|让我把所有的东西分开，然后孤立地解决每个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|231768|Authentication|offset|length|style|BOLD|231769|对于身份验证，baseauth的优势在于它在协议层是一个成熟的解决方案。这意味着很多“以后可能会出现”的问题已经为你解决了。例如，使用BaseAuth时，用户代理知道密码是密码，因此不会缓存它。|231770|身份验证服务器加载|231771|如果您将令牌分发给用户，而不是在服务器上缓存身份验证，那么您仍然在做同样的事情:缓存身份验证信息。唯一的区别是，您将缓存的责任推给了用户。对于用户来说，这似乎是不必要的工作，没有任何好处，所以我建议按照您的建议在服务器上透明地处理它。|231772|传输安全|231773|如果可以使用SSL连接，那就是所有的连接，连接是安全的。为了防止意外的多次执行，您可以过滤多个URL，或者要求用户在URL中包含一个随机组件("nonce")。|231774|url+=+username:key@myhost.com/api/call/nonce|code-block|syntax|javascript|231775|如果这是不可能的，并且传输的信息不是秘密的，我建议使用散列来保护请求，就像您在令牌方法中建议的那样。由于散列提供了安全性，因此您可以指示用户提供散列作为baseauth密码。为了提高健壮性，我建议使用随机字符串而不是时间戳作为“现时值”，以防止重放攻击(可以在同一秒内发出两个合法请求)。不需要提供单独的“共享密钥”和"api密钥“字段，只需使用api密钥作为共享密钥，然后使用不变的盐，以防止彩虹表攻击。用户名字段似乎也是放置nonce的好地方，因为它是auth的一部分。所以现在你有了一个干净的调用，如下所示：|231776|nonce+=+generate_secure_password(length:+16);
one_time_key+=+nonce+%2B+'-'+%2B+sha1(nonce%2Bsalt%2Bshared_key);
url+=+username:one_time_key@myhost.com/api/call|231777|这确实有点费力。这是因为您没有使用协议级解决方案(如SSL)。因此，向用户提供某种SDK可能是一个好主意，这样他们至少不必自己经历它。如果您需要这样做，我认为安全级别是合适的(just-right-kill)。|231778|安全机密存储|231779|这取决于你试图阻挠的是谁。如果您要阻止有权访问用户电话的人以用户的名义使用您的REST服务，那么在目标操作系统上找到某种密钥环API并让SDK+(或实现者)将密钥存储在目标操作系统上将是一个好主意。如果这是不可能的，你至少可以通过加密它，并将加密的数据和加密密钥存储在不同的地方，从而使获取秘密变得更加困难。|231780|如果您试图阻止其他软件供应商获得您的API密钥，以防止开发替代客户端，那么只有加密和存储分离的方法几乎是有效的。这是白盒加密，到目前为止，还没有人想出一个真正安全的解决方案来解决这类问题。您至少可以为每个用户颁发一个密钥，这样您就可以禁止滥用密钥。|231781|(*)+EDIT:+SSL+connections++without++The.|231782|entityMap^0|0|0|E|0|0|0|9|0|0|0|4|0|0|0|0|0|0|0|6|0|0|0|0|9|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1K|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1L|8|@$D|1M|E|1N|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1O|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1P|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|T|7|1R|8|@]|9|@]|A|$U|V]]|$1|10|3|11|5|6|7|1S|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1T|8|@$D|1U|E|1V|F|G]]|9|@]|A|$]]|$1|14|3|15|5|6|7|1W|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1X|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1Y|8|@$D|1Z|E|20|F|G]]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|1B|$]]

Let me seperate up everything and solve approach each problem in isolation:

Authentication

For authentication, baseauth has the advantage that it is a mature solution on the protocol level. This means a lot of "might crop up later" problems are already solved for you. For example, with BaseAuth, user agents know the password is a password so they don't cache it.

Auth server load

If you dispense a token to the user instead of caching the authentication on your server, you are still doing the same thing: Caching authentication information. The only difference is that you are turning the responsibility for the caching to the user. This seems like unnecessary labor for the user with no gains, so I recommend to handle this transparently on your server as you suggested.

Transmission Security

If can use an SSL connection, that's all there is to it, the connection is secure*. To prevent accidental multiple execution, you can filter multiple urls or ask users to include a random component ("nonce") in the URL.

<pre><code>url = username:key@myhost.com/api/call/nonce
</code></pre>

If that is not possible, and the transmitted information is not secret, I recommend securing the request with a hash, as you suggested in the token approach. Since the hash provides the security, you could instruct your users to provide the hash as the baseauth password. For improved robustness, I recommend using a random string instead of the timestamp as a "nonce" to prevent replay attacks (two legit requests could be made during the same second). Instead of providing seperate "shared secret" and "api key" fields, you can simply use the api key as shared secret, and then use a salt that doesn't change to prevent rainbow table attacks. The username field seems like a good place to put the nonce too, since it is part of the auth. So now you have a clean call like this:

<pre><code>nonce = generate_secure_password(length: 16);
one_time_key = nonce + '-' + sha1(nonce+salt+shared_key);
url = username:one_time_key@myhost.com/api/call
</code></pre>

It is true that this is a bit laborious. This is because you aren't using a protocol level solution (like SSL). So it might be a good idea to provide some kind of SDK to users so at least they don't have to go through it themselves. If you need to do it this way, I find the security level appropriate (just-right-kill).

Secure secret storage

It depends who you are trying to thwart. If you are preventing people with access to the user's phone from using your REST service in the user's name, then it would be a good idea to find some kind of keyring API on the target OS and have the SDK (or the implementor) store the key there. If that's not possible, you can at least make it a bit harder to get the secret by encrypting it, and storing the encrypted data and the encryption key in seperate places.

If you are trying to keep other software vendors from getting your API key to prevent the development of alternate clients, only the encrypt-and-store-seperately approach almost works. This is whitebox crypto, and to date, no one has come up with a truly secure solution to problems of this class. The least you can do is still issue a single key for each user so you can ban abused keys.

(*) EDIT: SSL connections <a href="http://heartbleed.com/" rel="noreferrer">should no longer be considered secure</a> without <a href="http://filippo.io/Heartbleed/#stackoverflow.com" rel="noreferrer">taking additional steps to verify</a> them.

blocks|key|231794|text|纯RESTful应用程序接口应该使用底层协议标准特性：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|231795|对于HTTP的|231796|，RESTful接口应该符合现有的HTTP标准头。添加新的HTTP头违反了REST原则。不要重复发明轮子，使用HTTP/1.1标准中的所有标准特性-包括状态响应码、标头等。HTTP服务应该利用并依赖于standards.|unordered-list-item|231797|
|231798|RESTful服务必须是无状态的。任何技巧，比如试图记住服务器上以前REST请求状态的基于令牌的身份验证，都违反了REST原则。同样，这也是必须的；也就是说，如果您的web服务器将任何与请求/响应上下文相关的信息保存在服务器上，以尝试在服务器上建立任何类型的会话，那么您的web服务就不是无状态的。如果它不是无状态的，那么它就不是RESTFul。|231799|231800|底线:出于身份验证/授权的目的，您应该使用HTTP标准的authorization头。也就是说，您应该在每个需要进行身份验证的后续请求中添加HTTP授权/身份验证头。REST+API应遵循HTTP+Authentication+Scheme+standards.The，有关如何格式化此报头的详细信息，请参阅RFC2616HTTP1.1标准-RFC2616的14.8授权，以及RFC2617HTTP验证:基本和摘要访问验证。|231801|我已经为Cisco+Prime+Performance+Manager应用程序开发了RESTful服务。在谷歌上搜索我为该应用程序编写的REST+API文档，了解有关RESTFul+API遵从性here的更多详细信息。在实现中，我选择使用HTTP“基本”授权方案。-检出REST+API文档的1.5版或更高版本，并在文档中搜索授权。|offset|length|231802|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cisco.com/c/en/us/support/cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html^0|0|0|0|0|0|0|0|2P|4|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|13|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@$P|17|Q|18|1|19]]|A|$]]|$1|R|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

A pure RESTful API should use the underlying protocol standard features:

<ol>
<li>For HTTP, the RESTful API should comply with existing HTTP standard headers. Adding a new HTTP header violates the REST principles. Do not re-invent the wheel, use all the standard features in HTTP/1.1 standards - including status response codes, headers, and so on. RESTFul web services should leverage and rely upon the HTTP standards.</li>
<li>RESTful services MUST be STATELESS. Any tricks, such as token based authentication that attempts to remember the state of previous REST requests on the server violates the REST principles. Again, this is a MUST; that is, if you web server saves any request/response context related information on the server in attempt to establish any sort of session on the server, then your web service is NOT Stateless. And if it is NOT stateless it is NOT RESTFul.</li>
</ol>

Bottom-line: For authentication/authorization purposes you should use HTTP standard authorization header. That is, you should add the HTTP authorization / authentication header in each subsequent request that needs to be authenticated. The REST API should follow the HTTP Authentication Scheme standards.The specifics of how this header should be formatted are defined in the RFC 2616 HTTP 1.1 standards – section 14.8 Authorization of RFC 2616, and in the RFC 2617 HTTP Authentication: Basic and Digest Access Authentication.

I have developed a RESTful service for the Cisco Prime Performance Manager application. Search Google for the REST API document that I wrote for that application for more details about RESTFul API compliance <a href="http://www.cisco.com/c/en/us/support/cloud-systems-management/prime-performance-manager/products-programming-reference-guides-list.html" rel="noreferrer">here</a>. In that implementation, I have chosen to use HTTP "Basic" Authorization scheme. - check out version 1.5 or above of that REST API document, and search for authorization in the document.

blocks|key|2897642|text|在web中，有状态协议基于在每次请求时在浏览器和服务器之间交换的临时令牌(通过cookie报头或URI重写)。该令牌通常是在服务器端创建的，它是一段具有特定生存时间的不透明数据，其唯一目的是标识特定的web用户代理。也就是说，令牌是临时的，并且成为web服务器在该对话期间必须代表客户端用户代理保持的状态。因此，以这种方式使用令牌的通信是有状态的。如果客户端和服务器之间的会话是有状态的，那么它就不是RESTful。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2897643|用户名/密码(在Authorization头上发送)通常保存在数据库中，目的是识别用户。有时，用户可能表示另一个应用程序；但是，用户名/密码永远不会用于标识特定的web客户端用户代理。web代理和服务器之间基于使用Authorization标头中的用户名/密码(在HTTP+Basic+Authorization之后)的会话是无状态的，因为web服务器前端不会代表特定的web客户端用户代理创建或维护任何状态信息。根据我对REST的理解，该协议明确规定客户端和服务器之间的会话应该是无状态的。因此，如果我们想要有一个真正的RESTful服务，我们应该在每个单独的调用的授权头中使用用户名/密码(请参考我上一篇文章中提到的RFC+)，而不是sension类型的令牌(例如，在web服务器中创建的会话令牌，在授权服务器中创建的OAuth令牌，等等)。|2897644|据我所知，一些被调用的REST提供者正在使用像OAuth1或OAuth2+accept这样的令牌--令牌在HTTP头中作为"Authorization:+Bearer“传递。然而，在我看来，将这些令牌用于RESTful服务将违背REST所包含的真正的无状态含义；因为这些令牌是在服务器端创建/维护的临时数据片段，用于在web客户端/服务器对话的有效持续时间内识别特定的web客户端用户代理。因此，如果我们想坚持无状态协议的真正含义，任何使用这些OAuth1/2令牌的服务都不应该被称为REST。|2897645|鲁本斯|2897646|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In the web a stateful protocol is based on having a temporary token that is exchanged between a browser and a server (via cookie header or URI rewriting) on every request. That token is usually created on the server end, and it is a piece of opaque data that has a certain time-to-live, and it has the sole purpose of identifying a specific web user agent. That is, the token is temporary, and becomes a STATE that the web server has to maintain on behalf of a client user agent during the duration of that conversation. Therefore, the communication using a token in this way is STATEFUL. And if the conversation between client and server is STATEFUL it is not RESTful. 

The username/password (sent on the Authorization header) is usually persisted on the database with the intent of identifying a user. Sometimes the user could mean another application; however, the username/password is NEVER intended to identify a specific web client user agent. The conversation between a web agent and server based on using the username/password in the Authorization header (following the HTTP Basic Authorization) is STATELESS because the web server front-end is not creating or maintaining any STATE information whatsoever on behalf of a specific web client user agent. And based on my understanding of REST, the protocol states clearly that the conversation between clients and server should be STATELESS. Therefore, if we want to have a true RESTful service we should use username/password (Refer to RFC mentioned in my previous post) in the Authorization header for every single call, NOT a sension kind of token (e.g. Session tokens created in web servers, OAuth tokens created in authorization servers, and so on).

I understand that several called REST providers are using tokens like OAuth1 or OAuth2 accept-tokens to be be passed as "Authorization: Bearer " in HTTP headers. However, it appears to me that using those tokens for RESTful services would violate the true STATELESS meaning that REST embraces; because those tokens are temporary piece of data created/maintained on the server side to identify a specific web client user agent for the valid duration of a that web client/server conversation. Therefore, any service that is using those OAuth1/2 tokens should not be called REST if we want to stick to the TRUE meaning of a STATELESS protocol.

Rubens

I'm developing a REST API that requires authentication. Because the authentication itself occurs via an external webservice over HTTP, I reasoned that we would dispense tokens to avoid repeatedly calling the authentication service. Which brings me neatly to my first question:

Is this really any better than just requiring clients to use HTTP Basic Auth on each request and caching calls to the authentication service server-side?

The Basic Auth solution has the advantage of not requiring a full round-trip to the server before requests for content can begin. Tokens can potentially be more flexible in scope (i.e. only grant rights to particular resources or actions), but that seems more appropriate to the OAuth context than my simpler use case.

Currently tokens are acquired like this:

<pre><code>curl -X POST localhost/token --data "api_key=81169d80...
 &amp;verifier=2f5ae51a...
 &amp;timestamp=1234567
 &amp;user=foo
 &amp;pass=bar"
</code></pre>

The <code>api_key</code>, <code>timestamp</code> and <code>verifier</code> are required by all requests. The "verifier" is returned by:

<pre><code>sha1(timestamp + api_key + shared_secret)
</code></pre>

My intention is to only allow calls from known parties, and to prevent calls from being reused verbatim.

Is this good enough? Underkill? Overkill?

With a token in hand, clients can acquire resources:

<pre><code>curl localhost/posts?api_key=81169d80...
 &amp;verifier=81169d80...
 &amp;token=9fUyas64...
 &amp;timestamp=1234567
</code></pre>

For the simplest call possible, this seems kind of horribly verbose. Considering the <code>shared_secret</code> will wind up being embedded in (at minimum) an iOS application, from which I would assume it can be extracted, is this even offering anything beyond a false sense of security?

REST API Token-based Authentication

身份验证

数据库

服务器

OAuth

我正在开发一个需要身份验证的REST API。由于身份验证本身是通过HTTP上的外部we服务进行的，因此我推断我们应该分发令牌，以避免重复调用身份验证服务。这就引出了我的第一个问题：这真的比仅仅要求客户端对每个请求使用HTTP Basic Auth并将调用缓存到身份验证服务服务器端更好吗？基本身份验证解决方案的优势在于...

问基于REST API令牌的身份验证
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基于REST API令牌的身份验证EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基于REST API令牌的身份验证
EN