本文翻译自RisingStack网站Gergely Nemeth撰写的《Web Authentication Methods Explained》一文，感谢景庄对该文章的翻译。
安全问题正成为Web应用越来越值得关注的问题。在这之前，我们已经讨论了 Node.js的安全问题列表。 为了更深入地探讨此类问题，本文将具体谈一谈有关Cookie、Token、以及其他Web认证方法。 本文将从最简单的HTTP基本认证开始谈起，进而会讨论Cookie、Token、签名，以及一次性密码结束。
HTTP基本认证
HTTP基本认证是最简单的一种Web认证方法，它通过在构造请求时提供用户名和密码的方式来提供认证。
之所以说HTTP基本认证是最简单的方法，是因为它不许要借组诸如Cookie，Session，或者其他数据。 如果要使用HTTP基本认证，客户端必须对于每一个构造的请求都要增加Authorization请求头。 用户名和密码可以不加密，但需要按照如下方法进行构造：
- 用户名和密码需要拼接为单个字符串，格式为：username:password。
- 字符串需要使用Base64进行编码。
- 在编码的值之前需要使用Basic作为关键字。
举个简单的例子，假如某个用户的用户名为john，密码为secret：
curl --header "Authorization: Basic am9objpzZWNyZXQ=" my-website.com
你可以在Chrome中看到类似的信息：
在Node.js中实现HTTP基本认证非常的简单，下面的代码片段展示了如何在Express中使用中间件的方式来实现HTTP基本认证：
import basicAusth from 'basicAuth';
function unauthorized(res) {
res.set('WWW-Authenticate', 'Basic realm=Authorization Required');
return res.send(401);
}
export default function auth(req, res, next) {
const {name, pass} = basicAuth(req) || {};
if (!name || !pass) {
return unauthorized(res);
}
if (name === 'john' && pass === 'secret') {
return next;
}
return unauthorized(res);
}当然，你可以在更高层达到这个目的，例如在 nginx中进行配置。
缺点
这看起来很简单是不是？那么HTTP基本认证的缺点是什么呢？如下：
- 每个请求都需要附加用户名和密码后进行发送，即使在使用安全连接的情况下，也会有数据泄漏的可能性。
- 联系到SSL/TLS，如果网站使用的较弱加密方法，或者某个攻击者破解了它，那么用户名和密码会立即被暴露。
- 使用HTTP基本认证无法注销用户的登录状态
- 证书不会过期——你必须要求用户自己来更改密码来达到这一目的
Cookie
对于服务器而言，当它需要对接收到的HTTP请求进行响应时，可以在响应头中添加Set-Cookie头。 浏览器会将该信息存放到一个Cookie容器中，如果设置在CookieHTTP头中的请求源相同的话，那么每次请求都会附带有该Cookie信息。
可以使用Cookie来实现认证，但关键的准则需要遵守：
1. 始终使用HttpOnly Cookies
为了尽可能的避免XSS工具，在设置Cookie时需要始终使用HttpOnly标记。通过这种方式，Cookie将不会在客户端调用document.cookies中显示出来。
2. 始终使用被签名的Cookie (signed cookies)
通过使用签名的Cookie，可以在服务器端检测Cookie是否在客户端被修改过。
我们这个也可以在Chrome中查看到到这个信息。首先让我们来看看服务器中是如何设置Cookie的：
这之后，所有的请求都使用为指定域设置的cookie（上面设置的域为domain=.linkedin.com;）：
缺点
- 为了尽可能避免 CSRF攻击，需要额外的工作。
- 和REST不兼容——因为它在无状态协议中引入了状态。
Tokens
如今JWT（JSON Web Token）随处可见——这里仍然有必要看看这其中潜在的安全问题。
我们首先来看下什么是JWT。JWT包括三个部分：
- 头部，包括token的类别和哈希算法。
- 载荷（Payload），包含着声明（claims）信息。
- 签名，如果选择HMAC SHA256的话，可以使用如下方法计算：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
在Koa应用中加入JWT只需要几行代码：
var koa = require('koa');
var jwt = require('koa-jwt');
var app = koa;
app.use(jwt({
secret: 'very-secret'
}));
// protected middleware
app.use(function * {
// content of the token will be available on this.state.user
this.body = {
secret: '42'
};
});示例用法（检查token的有效性或内容，可以使用 jwt.io）
curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" my-website.com
正如前面所说的那样，在Chrome中也可以看到tokens的内容：
如果你正在为原声移动应用或者SPA编写API的话，JWT会是一个非常不错的选择。有一点需要记住的是： 在浏览器中使用JWT你需要将它存在LocalStorage或者SessionStorage中，但这可能会导致XSS攻击。
缺点
如果要 避免XSS攻击需要额外的工作。
签名 Signatures
无论是使用Cookie还是Token，如果某种原因导致你的传输层被暴露的话，你的证书很容易被获取到， 攻击者很容易利用你的Cookie或Token来伪装成你的真实身份。
解决该问题的一个可行方案是对请求进行签名，这里主要讨论的是API而不是浏览器来对请求签名。这是如何工作的呢？
当一个API的某个消费者准备构造请求时它必须提供签名，也就是说它必须使用私钥来对整个请求创建哈希。 对于这个哈希计算你可能会使用到：
- HTTP方法；
- 请求的路径；
- HTTP头；
- HTTP载荷的校验和（checksum）；
- 创建hash的私钥。
为了确保它能够正常工作，API的消费者和创建者都需要拥有相同的私钥。一旦你获得了签名，你需要将它附加到请求中， 可以使用查询字符串，也可以采用HTTP头的形式。当然最好在附加一个日期信息，通过日期来定义签名的过期时间。
为什么需要经历这些步骤？因为即使传输层被破解，攻击者也只能读取你的流量信息，而不能伪装成你的用户帐号， 如果攻击者没有私钥，攻击者就无法对请求进行签名。绝大部分的AWS服务使用的都是这种认证方法。
node-http-signature模块提供了对HTTP请求签名的支持。
缺点
无法在浏览器或者客户端使用，只能在API之间使用。
一次性密码 One-Time Password
一次性密码算法使用一个共享的密钥和当前的时间或者计数器来生成一次性密码：
- 基于时间的一次性密码算法，基于当前的时间；
- 基于HMAC的一次性密码算法，基于计数器。
这些方法可以用在使用双因素认证的应用中：当用户如键入用户密码和密码的时候，在服务器和客户端都会生成一次性密码。
在Node.js中，可以使用 notp模块来轻松的实现一次性密码。
缺点
- 因为使用的是共享密钥，如果该信息被盗，则token可以被伪造；
- 因为客户端可以被窃取/出错，每个实时应用都有方法绕过这个，例如电子邮箱的重置会给应用增加附加的攻击风险。
如何选择Web认证方法
如果你只是用来支持一个Web应用，使用Cookie或者Token都可以，使用Cookie的时候你需要考虑XSRF， 使用JWT时你需要考虑XSS。如果你需要同时支持Web应用和移动应用，使用支持基于token认证的API。 如果你构建的API会进行彼此通信，使用请求签名。
译者简介：景庄，前端工程师，关注Node.js、前端工程化。个人博客：http://wwsun.github.com。
欢迎加入CSDN前端交流群2：465281214，进行前端技术交流。