token简述
目录
- 前言
- 1.什么是 token
- 2. 使用Token的意义
- 3. 基于Token的身份验证
- 3.2 Token常用的两种使用方式
- 3.2.1 用设备号 / 设备MAC地址作为Token
- 5. Token实现思路
- 6. Token优势
- 6.1 无状态、可扩展
- 6.2 安全性
- 6.3 可扩展性
- 6.4 多平台跨域
- 6.5 基于标准
前言
对于初学者来说，对Token这个玩意儿比较陌生，根据手头资料和自己粗浅的认知，在这里简明扼要地介绍一下。
1.什么是 token
Token： 是当第一次登录后，由服务端生成的一串字符串（即Token）。此字符串会返回给客户端。以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
当客户端频繁向服务端请求数据、服务端频繁的去数据库查询用户名和密码并进行对比时，Token将被作为客户端请求的一个令牌，服务端据此判断用户名和密码正确与否。
2. 使用Token的意义
减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
了解了Token的意义后，我们就更明确的知道为什么要用它了。
3. 基于Token的身份验证
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。流程如下：
如，APP 登录时发送加密的用户名和密码到服务器，服务器验证用户名和密码，验证成功，则以某种方式（比如随机生成32位的字符串作为 token）存储到服务器中，并返回 token 到APP。
后续当APP发起请求时，凡是需验证的地方都携带上该token供服务器端验证，验证成功就返回所需结果；验证失败则返回错误信息，并要求重新登录（注：服务器上 token 需设置有效期，每次 APP 发起请求时，验证 token 和有效期）。
3.2 Token常用的两种使用方式
3.2.1 用设备号 / 设备MAC地址作为Token
客户端： 客户端在登录的时候获取设备的设备号/MAC地址，并将其作为参数传递到服务端。
服务端： 服务端接收到该参数后，便用一个变量来接收，同时将其作为Token保存在数据库，并将该Token设置到session中，客户端每次请求的时候都要统一拦截，并将客户端传递的token和服务器端session中的token进行对比，如果相同则放行，不同则拒绝。
分析： 此刻客户端和服务器端就统一了一个唯一的标识Token，而且保证了每一个设备拥有了一个唯一的会话。
缺点：
客户端需要带设备号/MAC地址作为参数传递，而且服务器端还需要保存；在网络不好或者并发请求时，会导致多次重复提交数据的问题。
优点： 客户端不需重新登录，只要登录一次以后一直可以使用，至于超时的问题由服务器这边处理：
若服务器的Token超时，服务器只需将客户端传递的 Token 向数据库中查询，同时赋值给变量Token，如此，Token的超时又重新计时。
### 3.2.2 用session值作为Token **客户端：** 客户端只需携带用户名和密码登陆即可。
客户端： 客户端接收到用户名和密码后并判断，如果正确了就将本地获取 sessionID 作为 Token 返回给客户端，客户端以后只需带上请求数据即可。
优点： 方便，不用存储数据；
缺点： 当 session 过期后，客户端必须重新登录才能进行访问数据。
# 4. Token原理 
- 将荷载payload，以及Header信息进行Base64加密，形成密文payload密文，header密文；
- 将形成的密文用句号链接起来，用服务端秘钥进行HS256加密，生成签名；
- 将前面的两个密文后面用句号链接签名形成最终的token返回给服务端
注：
- 用户请求时携带此token(分为三部分，header 密文，payload 密文，签名)到服务端，服务端解析第一部分( header 密文)，用 Base64 解密，可以知道用了什么算法进行签名，此处解析发现是 HS256；
- 服务端使用原来的秘钥与密文( header 密文+"."+payload 密文)同样进行 HS256 运算，然后用生成的签名与 token 携带的签名进行对比，若一致说明 token 合法，不一致说明原文被修改；
- 判断是否过期，客户端通过用 Base64 解密第二部分（payload密文），可以知道荷载中授权时间，以及有效期。通过这个与当前时间对比发现token是否过期。
5. Token实现思路
- 客户端每次访问API均携带Token；
- 服务器端采用 filter 过滤器校验。校验成功就返回请求数据，校验失败则返回错误码。
6. Token优势
6.1 无状态、可扩展
在客户端存储的 Tokens 是无状态的，并且能够被扩展。基于这种无状态和不存储 Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。如果我们将已验证的用户的信息保存在 Session 中，则每次请求都需要用户向已验证的服务器发送验证信息(称为 Session 亲和性)。用户量大时，可能会造成 一些拥堵。但是不要着急。使用 tokens 之后这些问题都迎刃而解，因为 tokens 自己 hold 住了用户的验证信息。
6.2 安全性
请求中发送 token 而不再是发送 cookie 能够防止 CSRF (跨站请求伪造)。即使在客户端使用 cookie 存储 token，cookie 也仅仅是一个存储机制而不是用于认证。不将信息存储在 Session 中，让我们少了对 session 操作。token 是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到 token 自动失效，token 有撤回的操作，通过 token revocataion 可以使一个特定的 token 或是一组有相同认证的 token 无效。
6.3 可扩展性
Tokens 能够创建与其它程序共享权限的程序。例如，能将一个任意的社交帐号和自己的大号( Fackbook 或是 Twitter)联系起来。当通过服务登录 Twitter (我们将这个过程 Buffer)时，我们可以将这些 Buffer 附到 Twitter 的数据流上。使用 tokens 时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的 API，得出特殊权限的 tokens。
6.4 多平台跨域
我们提前先来谈论一下 CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。只要用户有一个通过了验证的 token，数据和资源就能够在任何域上被请求到。Access-Control-Allow-Origin: *
6.5 基于标准
创建 token 的时候，你可以设定一些选项。但是标准的用法会在 JSON Web Tokens体现。最近的程序和文档是供给 JSON Web Tokens 的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。
文中如有错误，敬请批评指正！~