Token是什么 Token登录认证

Token 是在服务端产生的一串字符串。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。

基于 Token 的身份验证，在服务端不需要存储用户的登录记录：

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
7. APP登录的时候发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果成功，以某种方式比如随机生成32位的字符串作为token，存储到服务器中，并返回token到APP，以后APP请求时
8. 凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让他重新登录。其中服务器上token设置一个有效期，每次APP请求的时候都验证token和有效期

Token 都需要设有效期。根据系统的安全需要，尽可能的短

基于token的认证方式

在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式

以下几点特性会让你在程序中使用基于Token的身份验证

1.无状态、可扩展

2.支持移动设备

3.跨程序调用

4.安全

Token的起源

在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。

• 基于服务器的验证

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。

在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。

• 基于服务器验证方式暴露的一些问题

1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。

2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。

3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。

4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。

在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。

**

基于Token的验证原理

**
基于Token的身份验证是无状态的，我们不将用户信息存在服务器中。这种概念解决了在服务端存储信息时的许多问题。NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

1.用户通过用户名和密码发送请求。

2.服务器端程序验证。

3.服务器端程序返回一个带签名的token 给客户端。

4.客户端储存token,并且每次访问API都携带Token到服务器端的。

5.服务端验证token，校验成功则
返回请求数据，校验失败则返回错误码。

Tokens的优势

• 无状态、可扩展

在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
tokens自己hold住了用户的验证信息。

• 安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。

token是有时效的，一段时间之后用户需要重新验证。

• 可扩展性

Tokens能够创建与其它程序共享权限的程序。

• 多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

需要设置有效期吗？

对于这个问题，我们不妨先看两个例子。一个例子是登录密码，一般要求定期改变密码，以防止泄漏，所以密码是有有效期的；另一个例子是安全证书。SSL 安全证书都有有效期，目的是为了解决吊销的问题。所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token 都需要设有效期。

• 那么有效期多长合适呢？

只能说，根据系统的安全需要，尽可能的短，但也不能短得离谱

• 然后新问题产生了，如果用户在正常操作的过程中，Token 过期失效了，要求用户重新登录……用户体验岂不是很糟糕？

一种方案，使用 Refresh Token，它可以避免频繁的读写操作。这种方案中，服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新Token 继续使用。这种方案中，服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。

• 时序图表示

使用 Token 和 Refresh Token 的时序图如下：

1）登录

2）业务请求

3）Token过期，刷新 Token

上面的时序图中并未提到 Refresh Token 过期怎么办。不过很显然，Refresh Token 既然已经过期，就该要求用户重新登录了。

项目中使用token总结

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

1.前端使用用户名跟密码请求首次登录

2.后服务端收到请求，去验证用户名与密码是否正确

3.验证成功后，服务端会根据用户id、用户名、定义好的秘钥、过期时间生成一个 Token，再把这个 Token 发送给前端

4.前端收到 返回的Token ，把它存储起来，比如放在 Cookie 里或者 Local Storage 里

 export interface User {
     token: string;
     userInfo: UserInfo | any;
     companyInfo: CompanyInfo | any;
     resources?: string[]; }

 save(key: string, value: any, storageType ?: StorageType) {
    return this.storageService.put(
        {
            pool: key,
            key: 'chris-app',
            storageType: StorageType.localStorage
      },
        value
    );
  }
  this.storageService.save(CACHE_USER_KEY, user);

5.前端每次路由跳转，判断 localStroage 有无 token ，没有则跳转到登录页。有则请求获取用户信息，改变登录状态；
6.前端每次向服务端请求资源的时候需要在请求头里携带服务端签发的Token

HttpInterceptor => headers = headers.set('token', this.authService.getToken());

7.服务端收到请求，然后去验证前端请求里面带着的 Token。没有或者 token 过期，返回401。如果验证成功，就向前端返回请求的数据。

8.前端得到 401 状态码，重定向到登录页面。

HttpInterceptor => 
    401: '用户登陆状态失效，请重新登陆。'