[译]Cookies vs Tokens : 权威指南

发表于 更新于 分类于

本文译自：Cookies vs Tokens: The Definitive Guide

TL;DR

基于令牌的身份验证（Tokens-based authentication，下文简写为token）正在变得越来越流行。 我们将研究cookie和token之间的区别和相似之处，使用token的优势，以及解决开发人员关于token的常见问题和疑虑。 最后，我们将构建一个使用token并使其成为渐进式Web应用程序（PWA）的应用程序。

我们将编写一个使用JWT进行身份验证的Angular 2应用程序。源码在此: GitHub repo。

我们上一篇对比cookie和token的文章是在两年前*(译者注：本文发表于2016年5月31日)*。从那以后，我们已经写了很多关于如何在不同语言和框架中集成token的文章。

单页面应用程序（SPA）的兴起以及前后端分离是非常有效的。 像Angular、React和Vue这样的框架允许开发人员构建比以前更强大、更高性能的单页应用程序。 而token可以与这些框架结合在一起使用。

“Token-based authentication goes hand in hand with SPA frameworks like Angular, React and Vue.”

Cookie vs Token Authentication - 概览

在我们进一步深入之前，让我们快速回顾一下这两种认证系统是如何工作的。如果您已经熟悉cookie和token的工作原理，请跳过本节，否则请继续阅读。

下图简要概述了cookie和token认证方法之间的区别。

基于Cookie的身份验证

基于Cookie的身份验证早已成为处理用户认证的默认和可靠的方法。

基于cookie的身份验证是有状态的。这意味着认证记录或会话（session）在服务器端和客户端都要保存。服务器需要跟踪数据库中的活动session，而在前端也要创建一个包含session标识符的cookie，从而实现基于cookie的身份验证。我们来看看传统的基于cookie的认证流程：

  1. 用户输入他们的登录凭证
  2. 服务器验证凭据是否正确，并创建一个session，然后将其存储在数据库中
  3. 具有session ID的cookie被放置在用户浏览器中（译者注：注意这里是session ID，不是session）
  4. 在随后的请求中，将根据数据库验证session ID，并且判断请求是否有效
  5. 一旦用户注销了应用程序，客户端和服务器端的session就会被销毁

基于Token的身份验证

由于SPA、Web API和物联网（IoT）的兴起，token在过去几年得到了普及。当我们谈论token时，我们通常会谈论使用JSON Web Tokens（JWT）进行身份验证。尽管实现token的方式有所不同，但JWT已成为事实上的标准。考虑到这种情况，本文的其余部分将交替使用token和JWT。

基于token的认证是无状态的。服务器不记录哪些用户已登录或哪些JWT已发出。与之相对，对服务器的每个请求都伴随着一个token，服务器使用该token来验证请求的真实性。该token通常以{JWT}的形式作为附加header发送，但也可以在POST请求的主体中发送，甚至作为查询参数发送。让我们看看这个流程是如何工作的：

  1. 用户输入他们的登录凭证
  2. 服务器验证凭据是否正确并返回签名过的token
  3. 该token存储在客户端，通常存储在本地存储（local storage）中，但也可以存储在会话存储（session storage）或cookie中
  4. 对服务器的后续请求将此token包含为额外的header，或通过上述其他方法之一
  5. 服务器解码JWT，如果token有效，则处理该请求
  6. 一旦用户注销，token就会被销毁，并且客户端不需要与服务器交互

基于Token身份验证的优势

只了解认证过程还不够。接下来，我们将介绍token优于cookie方案的原因。

无状态，可扩展和解耦

将token存储在cookie中，最大的好处可能在于token是无状态的。后端不需要记录token。每个token都是独立的，包含检查其有效性以及通过声明传达用户信息所需的所有数据。

服务器的唯一工作就是在成功的登录请求上签名token，并验证传入token是否有效。事实上，服务器甚至不需要对token进行签名。第三方服务（如Auth0）可以处理token的发放，然后服务器只需验证token的有效性。（译者注：作者夹带私货）

跨域（Cross Domain）和跨域资源共享（CORS）

Cookie可以很好地处理单个域名和子域名，但是当涉及跨不同域名管理Cookie时，它可能会变得复杂。相反，token使得将API公开给不同的服务和域变得简单。每次调用后端时，都通过JWT对token进行校验，只要token有效就可以处理请求。这里有一些注意事项，我们将在下面的常见问题和关注部分讨论这些问题。

将数据存储在JWT中

在使用基于cookie的身份验证时，您只是将session ID存储在cookie中。而JWT则允许您存储任何类型的元数据，只要它是有效的JSON。JWT规范指定了元数据中可以包含的不同类型的声明，例如保留声明，公共声明和私有声明。您可以通过jwt.io网站了解各种声明的具体情况和差异。

实际上，这意味着JWT可以包含任何类型的数据。根据您的使用情况，您可以选择提供最少的声明，例如用户ID和token到期时间；或者您可以决定添加其他声明，例如用户电子邮件地址，颁发token的人员，范围或用户权限等等。

性能

在使用基于cookie的身份验证时，后端必须执行查询，无论是传统SQL数据库还是NoSQL，并且与解码token相比，整个流程可能需要更长的时间。此外，由于您可以将其他数据存储在JWT中，例如用户权限级别，因此您可以省去额外的获取和处理请求的数据的调用。
例如，假设您有一个，用于检索最新订单的API/api/orders，但只有admin权限的角色才能查看此数据。在基于cookie的方法中，一旦发出请求，您将需要一次请求数据库来验证会话有效，另一次请求以获取用户数据并验证用户是否具有admin权限，最后是第三个请求来获取数据。使用JWT方法，您可以将用户角色存储在JWT中，因此一旦提出请求并验证了JWT，您就可以对数据库进行唯一一次请求以检索订单。

移动端支持

现代API不仅与浏览器交互。正确编写一个API也可以为iOS和Android等浏览器和Native APP提供服务。原生移动平台和Cookie不能很好地融合。虽然可能，但在移动平台上使用cookie有许多限制和考虑因素。另一方面，token在iOS和Android上都更容易实现。对于没有cookie存储概念的物联网应用程序和服务，令牌也更容易实现。

常见问题和疑虑

在本节中，我们将看看token认证时经常出现的一些常见问题和疑虑。这里关注的焦点将是安全性，同时我们也会关注token的大小、存储和加密。

JWT的大小

token认证的最大缺点是JWT的大小。session cookie甚至比最小的JWT还要小。根据您的使用情况，如果您添加了多个声明，token的大小可能会变成一个问题。请记住，对服务器的每个请求都必须包含JWT。

在哪里存储token？

使用基于token的身份验证，您可以选择在哪里存储JWT。通常，JWT放置在浏览器本地存储（local storage）中，对于大多数使用情况来说，这种方式非常有效。将JWT存储在local storage中时需要注意一些问题。与cookie不同的是，local storage被沙箱化为特定的域，其数据不能被任何其他域（包括子域）访问。
您可以将token存储在cookie中，但cookie的最大大小仅为4kb，因此如果您有多个声明，则可能会产生问题。此外，您可以将token存储在与local storage类似的session storage中，但只要用户关闭浏览器就会被清除。

XSS和XSRF防护

保护用户和服务器始终是首要任务。开发人员在决定是否使用基于token的身份验证时最常遇到的问题之一是安全隐患。面向网站的两种最常见的攻击媒介是跨站脚本（XSS）和跨站请求伪造（XSRF或CSRF）。
XSS - 当外部实体能够在您的网站或应用程序内执行代码时发生攻击。这里最常见的攻击方法是，如果你的网站允许输入的信息没有被正确处理。如果攻击者可以在您的域上执行代码，那么您的JWT token易受攻击。我们的首席技术官过去认为，与XSRF攻击相比，XSS攻击更容易防范。许多框架，包括Angular，都会自动清理输入并防止任意代码执行。如果你没有使用框架来清理输入/输出，你可以尝试像google开发的caja插件。过滤输入是许多框架和语言中尝试解决的问题，我会推荐使用框架或插件来构建自己的输入。
如果您在local storage中使用JWT，则跨站请求伪造攻击不是问题。另一方面，如果您期望JWT存储在cookie中，则需要防范XSRF。XSRF的原理不像XSS攻击那么容易理解。解释XSRF攻击如何工作可能非常耗时，所以，请查看本指南，深入解释XSRF攻击如何工作。幸运的是，防范XSRF攻击是一件相当简单的事情。为了防止XSRF攻击，您的服务器在建立与客户端的会话时将生成唯一的token（请注意，这不是JWT）。然后，无论何时将数据提交给服务器，隐藏的输入字段都将包含此token，并且服务器将检查以确保token匹配。同样，由于我们的建议是将JWT存储在local storage中，因此您可能不必担心XSRF攻击。
保护用户和服务器的最佳方式之一是token的过期时间很短。这样，即使token被泄露，它也会很快变得无效。此外，您可能会维护一个被盗用token的黑名单，并且不允许这些令牌访问系统。您还可以通过改变签名算法作为最终手段，这会使所有有效令牌失效并要求所有用户再次登录。当然这种方法不推荐，但在严重情况下可用。

token已签名，未加密

一个JWT由三部分组成：header, payload和signature。JWT的格式是header.payload.signature。如果我们要用HMACSHA256算法签名JWT，secret是’shhhh’和下面的payload：

1
2
3
4
5
{
  "sub": "1234567890",
  "name": "Ado Kukic",
  "admin": true
}

生成的JWT将是：

QiOjE0NjQyOTc4ODV9.Y47kJvnHzU9qeJIN48_bVna6O0EDFiMiQ9LpNVDFymM

这里需要注意的是，这个token是由HMACSHA256算法签名的，header和payload是Base64URL编码的，它没有加密。如果我访问jwt.io，粘贴此token并选择HMACSHA256算法，我可以解码并读取其内容。因此，不应该将敏感数据（如密码）存储在payload中。
如果您必须将敏感数据存储在有效内容中，或者您需要屏蔽JWT，则可以使用JSON Web Encryption（JWE）。JWE允许您加密JWT的内容，以便除服务器之外的任何人都无法读取它。JOSE为JWE提供了一个很好的框架和不同的选项，并且为许多流行的框架（包括NodeJS和Java）提供了SDK。无论如何，我鼓励您了解更多关于AngularJS身份验证的信息。

使用Auth0进行基于Token的身份验证

以下为机翻内容
在Auth0中，我们编写了SDK，指南和快速入门，用于与JWT一起使用多种语言和框架，包括NodeJS，Java，Python，GoLang, 等等。我们最后的“Cookies与Tokens”文章使用了AngularJS框架，所以今天我们的代码样本适合使用Angular 2。
您可以从我们的由Kim Maida创建的GitHub仓库中下载示例代码。下载代码样本比较好，因为Angular 2需要很多初始设置才能开始。如果您尚未注册，请注册一个免费的Auth0帐户，以便您可以自己执行实施并尝试不同的功能和选项。让我们开始吧

另外：使用Auth0验证Angular App和Node API

我们可以保护我们的应用程序和API，以便只有经过身份验证的用户才能访问它们。我们来看看如何使用Auth0来实现Angular应用程序和Node API。您可以从GitHub上的angular-auth0-aside回购中克隆此示例应用程序和API。

功能

示例Angular应用程序和API具有以下功能：

  • Angular CLI生成Angular应用程序，并在http://localhost:4200处提供服务
  • 使用登录页面进行auth0.js身份验证
  • 节点服务器保护的API路由http://localhost:3001/api/dragons返回经过验证的GET请求的JSON数据
  • 一旦用户使用Auth0进行身份验证，Angular app就会从API中获取数据
  • 配置文件页面需要使用路由防护进行身份验证
  • 身份验证服务使用主题将身份验证状态事件传播到整个应用程序
  • 用户配置文件在认证时被提取并存储在认证服务中
  • 访问令牌，配置文件和令牌到期存储在本地存储中，并在注销时删除

注册Auth0

您需要一个Auth0帐户来管理身份验证。您可以在这里注册一个免费帐户。接下来，设置Auth0应用程序和API，以便Auth0可以与Angular应用程序和Node API进行交互。

设置一个Auth0应用程序

  1. 转到您的Auth0仪表板并点击“创建新应用程序”按钮。
  2. 命名您的新应用程序并选择“单页网络应用程序”。
  3. 在新的Auth0应用的设置中，将http://localhost:4200/callback添加到允许的回调URL中。点击“保存更改”按钮。
  4. 如果你愿意，你可以建立一些社交关系。然后，您可以在连接选项卡下的应用程序选项中为您的应用程序启用它们。上面的屏幕截图中显示的示例使用用户名/密码数据库，Facebook，Google和Twitter。对于制作，请确保您设置了自己的社交密钥，并且不要将社交连接设置为使用Auth0开发密钥。

注意：在高级设置的OAuth选项卡下（设置部分的底部），您应该看到JsonWebToken签名算法设置为RS256。这是新应用程序的默认设置。如果设置为HS256，请将其更改为RS256。您可以在这里阅读有关RS256与HS256 JWT签名算法的更多信息。

设置一个API

  1. 转到Auth0仪表板中的**API，然后单击“创建API”按钮。输入API的名称。将标识符**设置为您的API端点URL。在这个例子中，这是http://localhost:3001/api/。签名算法应该是RS256。
  2. 您可以参阅新API的设置中的快速启动选项卡下的Node.js示例。我们将以这种方式实现我们的Node API，使用Express，express-jwt和jwks-rsa。

我们现在准备在我们的Angular客户端和Node后端API上实现Auth0认证。

依赖和设置

Angular应用程序使用Angular CLI。确保您已全局安装CLI：

1
npm install -g @angular/cli

在克隆项目后，通过在项目文件夹的根目录中运行以下命令来安装Angular应用程序和Node服务器的节点依赖项：

1
2
3
npm install
cd server
npm install

Node API位于示例应用程序根目录下的/server文件夹中。
找到config.js.example文件并从文件名中删除.example扩展名。然后打开文件：

1
2
3
4
5
// server/config.js (formerly config.js.example)
module.exports = {
  CLIENT_DOMAIN: '[AUTH0_CLIENT_DOMAIN]', // e.g. 'you.auth0.com'
  AUTH0_AUDIENCE: 'http://localhost:3001/api/'
};

将AUTH0_CLIENT_DOMAIN标识符更改为您的Auth0应用程序域，并将AUTH0_AUDIENCE设置为您的受众（在本例中为http://localhost:3001/api/）。 /api/dragons路由将受到express-jwt和jwks-rsa的保护。

注意：要了解有关RS256和JSON Web密钥集的更多信息，请阅读导航RS256和JWKS。

我们的API现在受到保护，所以让我们确保我们的Angular应用程序也可以与Auth0进行交互。为此，我们将通过从文件扩展名中删除.example来激活src/app/auth/auth0-variables.ts.example文件。然后打开文件并将[AUTH0_CLIENT_ID]和[AUTH0_CLIENT_DOMAIN]字符串更改为Auth0信息：

1
2
3
4
5
6
// src/app/auth/auth0-variables.ts (formerly auth0-variables.ts.example)
...
export const AUTH_CONFIG: AuthConfig = {
  CLIENT_ID: '[AUTH0_CLIENT_ID]',
  CLIENT_DOMAIN: '[AUTH0_CLIENT_DOMAIN]',
  ...

我们的应用和API现在已经建立。它们可以通过运行根文件夹中的ng serve和来自/server文件夹的node server.js来运行。
随着Node API和Angular应用程序的运行，让我们来看看如何实现身份验证。

认证服务

使用AuthService认证服务处理前端的认证逻辑：src/app/auth/auth.service.ts文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
// src/app/auth/auth.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import * as auth0 from 'auth0-js';
import { AUTH_CONFIG } from './auth0-variables';
import { UserProfile } from './profile.model';

(window as any).global = window;

@Injectable()
export class AuthService {
  // Create Auth0 web auth instance
  // @TODO: Update AUTH_CONFIG and remove .example extension in src/app/auth/auth0-variables.ts.example
  private _auth0 = new auth0.WebAuth({
    clientID: AUTH_CONFIG.CLIENT_ID,
    domain: AUTH_CONFIG.CLIENT_DOMAIN,
    responseType: 'token',
    redirectUri: AUTH_CONFIG.REDIRECT,
    audience: AUTH_CONFIG.AUDIENCE,
    scope: AUTH_CONFIG.SCOPE
  });
  userProfile: UserProfile;
  accessToken: string;

  // Create a stream of logged in status to communicate throughout app
  loggedIn: boolean;
  loggedIn$ = new BehaviorSubject<boolean>(this.loggedIn);

  constructor() {
    // You can restore an unexpired authentication session on init
    // by using the checkSession() endpoint from auth0.js:
    // https://auth0.com/docs/libraries/auth0js/v9#using-checksession-to-acquire-new-tokens
  }

  private _setLoggedIn(value: boolean) {
    // Update login status subject
    this.loggedIn$.next(value);
    this.loggedIn = value;
  }

  login() {
    // Auth0 authorize request
    this._auth0.authorize();
  }

  handleLoginCallback() {
    // When Auth0 hash parsed, get profile
    this._auth0.parseHash((err, authResult) => {
      if (authResult && authResult.accessToken) {
        window.location.hash = '';
        this.getUserInfo(authResult);
      } else if (err) {
        console.error(`Error: ${err.error}`);
      }
    });
  }

  getUserInfo(authResult) {
    // Use access token to retrieve user's profile and set session
    this._auth0.client.userInfo(authResult.accessToken, (err, profile) => {
      this._setSession(authResult, profile);
    });
  }

  private _setSession(authResult, profile) {
    const expTime = authResult.expiresIn * 1000 + Date.now();
    // Save session data and update login status subject
    localStorage.setItem('expires_at', JSON.stringify(expTime));
    this.accessToken = authResult.accessToken;
    this.userProfile = profile;
    this._setLoggedIn(true);
  }

  logout() {
    // Remove token and profile and update login status subject
    localStorage.removeItem('expires_at');
    this.accessToken = undefined;
    this.userProfile = undefined;
    this._setLoggedIn(false);
  }

  get authenticated(): boolean {
    // Check if current date is greater than expiration
    // and user is currently logged in
    const expiresAt = JSON.parse(localStorage.getItem('expires_at'));
    return (Date.now() < expiresAt) && this.loggedIn;
  }

}

该服务使用来自auth0-variables.ts的配置变量实例化auth0.jsWebAuth实例。
RxJS BehaviorSubject用于提供一系列身份验证状态事件，您可以在应用程序的任何位置订阅这些事件。
login()方法使用你的配置变量授权带有Auth0的认证请求。登录页面将显示给用户，然后他们可以登录。

注意：如果用户第一次访问我们的应用程序，并且我们的回调位于localhost，那么他们还会看到一个同意屏幕，他们可以授予对我们API的访问权限。非本地主机域上的第一方客户端将被高度信任，因此在这种情况下不会出现同意对话框。您可以通过编辑Auth0 Dashboard API设置来修改此内容。查找“允许跳过用户同意”切换。

返回到我们的应用程序时，我们将在Auth0的哈希中接收accessToken和expiresIn。 handleLoginCallback()方法使用Auth0的parseHash()方法回调来获取用户的配置文件（getUserInfo()），并通过保存令牌，配置文件和令牌过期并更新loggedIn$主题来设置会话（_setSession()），通知应用程序中订阅的组件已通过身份验证。

注意：该配置文件采用OpenID标准声明中profile.model.ts的形式。

最后，我们有一个logout()方法，用于清除数据并更新loggedIn$主题。我们也有一个authenticated的访问者，根据令牌的存在和令牌的有效期限返回当前的身份验证状态。
一旦在app.module.ts中提供了AuthService，其方法和属性就可以在我们的应用程序的任何地方使用，例如家庭组件。

回调组件

回调组件是认证后应用程序重定向的地方。该组件只是在登录过程完成之前显示加载消息。它执行handleLoginCallback()方法来解析散列并提取认证信息。它在我们的认证服务中订阅了loggedIn$ Behaviour Subject，以便在用户登录后重定向回主页，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// src/app/callback/callback.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';
import { AuthService } from './../auth/auth.service';
import { Router } from '@angular/router';

@Component({
  selector: 'app-callback',
  templateUrl: './callback.component.html',
  styleUrls: ['./callback.component.css']
})
export class CallbackComponent implements OnInit, OnDestroy {
  loggedInSub: Subscription;

  constructor(private auth: AuthService, private router: Router) {
    // Parse authentication hash
    auth.handleLoginCallback();
  }

  ngOnInit() {
    this.loggedInSub = this.auth.loggedIn$.subscribe(
      loggedIn => loggedIn ? this.router.navigate(['/']) : null
    )
  }

  ngOnDestroy() {
    this.loggedInSub.unsubscribe();
  }

}

进行经过身份验证的API请求

为了进行经过验证的HTTP请求，我们需要在我们的api.service.ts文件中添加带有Authorization的标头。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// src/app/api.service.ts
import { Injectable } from '@angular/core';
import { throwError, Observable } from 'rxjs';
import { HttpClient, HttpHeaders, HttpErrorResponse } from '@angular/common/http';
import { catchError } from 'rxjs/operators';
import { AuthService } from './auth/auth.service';

@Injectable()
export class ApiService {
  private baseUrl = 'http://localhost:3001/api/';

  constructor(
    private http: HttpClient,
    private auth: AuthService
  ) { }

  getDragons$(): Observable<any[]> {
    return this.http
      .get<any[]>(`${this.baseUrl}dragons`, {
        headers: new HttpHeaders().set(
          'Authorization', `Bearer ${this.auth.accessToken}`
        )
      })
      .pipe(
        catchError(this._handleError)
      );
  }

  private _handleError(err: HttpErrorResponse | any) {
    const errorMsg = err.message || 'Unable to retrieve data';
    return throwError(errorMsg);
  }

}

最后：路由保护和配置文件页面

个人资料页面组件可以显示已验证的用户个人资料信息。但是，我们只希望该组件在用户登录时可访问。
通过认证的API请求和登录/注销实施，最后一步是保护我们的个人资料路线免受未经授权的访问。 auth.guard.ts路由守卫可以检查身份验证并有条件地激活路由。守卫在app-routing.module.ts文件中的特定路由上实现，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
// src/app/app-routing.module.ts
...
import { AuthGuard } from './auth/auth.guard';
...
      {
        path: 'profile',
        component: ProfileComponent,
        canActivate: [
          AuthGuard
        ]
      },
...

更多资源

我们拥有经过验证的Node API和Angular应用程序，包括登录，注销，个人资料信息和受保护的路线。要了解更多信息，请查看以下资源：

结论

在今天的文章中，我们比较了Cookie和基于令牌的身份验证之间的区别。我们强调了使用令牌的优势和关注点，并撰写了一个简单的应用程序来展示JWT在实践中的工作方式。使用令牌有很多原因，Auth0在这里确保实现令牌认证非常简单和安全。最后，我们引入了渐进式Web应用程序，帮助您的Web应用程序在移动设备上感受更原生。今天注册一个免费帐户，并在几分钟内启动并运行。