Hawk是一种新的http鉴权方案，它使用了MAC（message authentication code 消息鉴权码）来对http请求进行签名验证，进而起到保护http请求的目的。
这个方案的主要目标是：
（1）在不希望或者没有条件在每次请求中使用TLS的时候，简化和改进对服务请求的HTTP鉴权，
（2）在某些情况保护凭据免于泄露，例如：当客户端使用了某种动态的配置来决定往哪里发送鉴权过的请求的时候。
（3）在某些情况保护凭据免于暴露，例如：当客户端将凭证发送给某个恶意的服务器，此时使用了未经鉴权的安全通道，因为在TLS握手中客户端没有成功地对服务器的身份进行验证。
下面的示例代码使用了node.js和http报文。
Hawk is an HTTP authentication scheme using a message authentication code (MAC) algorithm to provide partial HTTP request cryptographic verification. For more complex use cases such as access delegation, see Oz.
Current version: 3.x
Note: 3.x and 2.x are the same exact protocol as 1.1. The version increments reflect changes in the node API.
Introduction
Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload.
Similar to the HTTP Digest access authentication schemes, Hawk uses a set of client credentials which include an identifier (e.g. username) and key (e.g. password). Likewise, just as with the Digest scheme, the key is never included in authenticated requests. Instead, it is used to calculate a request MAC value which is included in its place.
However, Hawk has several differences from Digest. In particular, while both use a nonce to limit the possibility of replay attacks, in Hawk the client generates the nonce and uses it in combination with a timestamp, leading to less "chattiness" (interaction with the server).
Also unlike Digest, this scheme is not intended to protect the key itself (the password in Digest) because the client and server must both have access to the key material in the clear.
The primary design goals of this scheme are to:
- simplify and improve HTTP authentication for services that are unwilling or unable to deploy TLS for all resources,
- secure credentials against leakage (e.g., when the client uses some form of dynamic configuration to determine where to send an authenticated request), and
- avoid the exposure of credentials sent to a malicious server over an unauthenticated secure channel due to client failure to validate the server's identity as part of its TLS handshake.
In addition, Hawk supports a method for granting third-parties temporary access to individual resources using a query parameter called bewit (in falconry, a leather strap used to attach a tracking device to the leg of a hawk).
The Hawk scheme requires the establishment of a shared symmetric key between the client and the server, which is beyond the scope of this module. Typically, the shared credentials are established via an initial TLS-protected phase or derived from some other shared confidential information available to both the client and the server.
Replay Protection
Without replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more than once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when making requests. This gives the server enough information to prevent replay attacks.
The nonce is generated by the client, and is a string unique across all requests with the same timestamp and key identifier combination.
The timestamp enables the server to restrict the validity period of the credentials where requests occuring afterwards are rejected. It also removes the need for the server to retain an unbounded number of nonce values for future checks. By default, Hawk uses a time window of 1 minute to allow for time skew between the client and server (which in practice translates to a maximum of 2 minutes as the skew can be positive or negative).
Using a timestamp requires the client's clock to be in sync with the server's clock. Hawk requires both the client clock and the server clock to use NTP to ensure synchronization. However, given the limitations of some client types (e.g. browsers) to deploy NTP, the server provides the client with its current time (in seconds precision) in response to a bad timestamp.
There is no expectation that the client will adjust its system clock to match the server (in fact, this would be a potential attack vector). Instead, the client only uses the server's time to calculate an offset used only for communications with that particular server. The protocol rewards clients with synchronized clocks by reducing the number of round trips required to authenticate the first request.
Usage Example
Server code:
var Http = require('http'); var Hawk = require('hawk'); // Credentials lookup function var credentialsFunc = function (id, callback) { var credentials = { key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn', algorithm: 'sha256', user: 'Steve' }; return callback(null, credentials); }; // Create HTTP server var handler = function (req, res) { // Authenticate incoming request Hawk.server.authenticate(req, credentialsFunc, {}, function (err, credentials, artifacts) { // Prepare response var payload = (!err ? 'Hello ' + credentials.user + ' ' + artifacts.ext : 'Shoosh!'); var headers = { 'Content-Type': 'text/plain' }; // Generate Server-Authorization response header var header = Hawk.server.header(credentials, artifacts, { payload: payload, contentType: headers['Content-Type'] }); headers['Server-Authorization'] = header; // Send the response back res.writeHead(!err ? 200 : 401, headers); res.end(payload); }); }; // Start server Http.createServer(handler).listen(8000, 'example.com');