Token概述（no session!）
简单来说：首先请求方输入自己的用户名，密码，然后 server 据此生成 token，客户端拿到 token 后会保存到本地（token存储在浏览器端），之后向 server 请求时在请求头带上此 token 即可（server有校验机制，检验token合法性，同时server通过token中携带的uid确定是谁在访问它）。
可以看到 token 主要由三部分组成：
header：指定了签名算法
payload：可以指定用户 id，过期时间等非敏感数据
Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。
当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。而且你会发现 payload 中存有我们的 userId，所以拿到 token 后直接在 payload 中就可获取 userid，避免了像 session 那样要从 redis 去取的开销。
你会发现这种方式确实很妙，只要 server 保证密钥不泄露，那么生成的 token 就是安全的，因为如果伪造 token 的话在签名验证环节是无法通过的，就此即可判定 token 非法。
可以看到通过这种方式有效地避免了 token 必须保存在 server 的弊端，实现了分布式存储，不过需要注意的是，token 一旦由 server 生成，它就是有效的，直到过期，无法让 token 失效，除非在 server 为 token 设立一个黑名单，在校验 token 前先过一遍此黑名单，如果在黑名单里则此 token 失效，但一旦这样做的话，那就意味着黑名单就必须保存在 server，这又回到了 session 的模式，那直接用 session 不香吗。所以一般的做法是当客户端登出要让 token 失效时，直接在本地移除 token 即可，下次登录重新生成 token 就好。
另外需要注意的是 token 一般是放在 header 的 Authorization 自定义头里，不是放在 Cookie 里的，这主要是为了解决跨域不能共享 Cookie 的问题
总结：token解决什么问题（为什么要用token）？
完全由应用管理，可以避开同源策略
支持跨域访问，cookie不支持， Cookie 跨站是不能共享的，这样的话如果你要实现多应用（多系统）的单点登录（SSO），使用 Cookie 来做需要的话就很困难了。但如果用 token 来实现 SSO 会非常简单，只要在 header 中的 authorize 字段（或其他自定义）加上 token 即可完成所有跨域站点的认证。
token是无状态的，可以在多个服务器间共享
token可以避免CSRF攻击（跨站请求攻击）
易于扩展，在移动端原生请求是没有 cookie 之说的，而 sessionid 依赖于 cookie，sessionid 就不能用 cookie 来传了，如果用 token 的话，由于它是随着 header 的 authoriize 传过来的，也就不存在此问题，换句话说token 天生支持移动平台，可扩展性好
拓展1：那啥是CSRF呢？
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过（cookie 里带来 sessionId 等身份认证的信息），所以被访问的网站会认为是真正的用户操作而去运行。
那么如果正常的用户误点了上面这张图片，由于相同域名的请求会自动带上 cookie，而 cookie 里带有正常登录用户的 sessionid，类似上面这样的转账操作在 server 就会成功，会造成极大的安全风险
CSRF 攻击的根本原因在于对于同样域名的每个请求来说，它的 cookie 都会被自动带上，这个是浏览器的机制决定的！
至于完成一次CSRF攻击必要的两个步骤：
1、首先登了一个正常的网站A，并且在本地生成了cookie
2、在cookie有效时间内，访问了危险网站B（就获取了身份信息）
Q：那我不访问危险网站就完了呗？
A：危险网站也许只是个存在漏洞的可信任网站！
Q：那我访问完正常网站，关了浏览器就好了呀？
A：即使关闭浏览器，cookie也不保证一定立即失效，而且关闭浏览器并不能结束会话，session的生命周期跟这些都没关系。
拓展2：同源策略？
就是不同源的客户端脚本在没有明确授权情况下，不准读写对方的资源！
同源就是：协议、域名与端口号都相同。
同源策略是由 Netscape 提出的著名安全策略，是浏览器最核心、基本的安全功能，它限制了一个源中加载脚本与来自其他源中资源的交互方式。
拓展3：什么是跨域，如何解决？
当浏览器执行脚本时会检查是否同源，只有同源的脚本才会执行，如果不同源即为跨域。
产生原因：它是由浏览器的同源策略造成的，是浏览器对JavaScript实施的安全限制。
解决方案：
nginx（静态服务器）反向代理解决跨域（前端常用），a明确访问c代理服务器，但是不知道c的内容从哪里来，c反向从别的地方拿来数据。(忽略的是目标地址)，浏览器可以访问a,而服务器之间不存在跨域问题，浏览器先访问a的服务器c，让c服务器作为代理去访问b服务器,拿到之后再返回数据给a。
jsonp：通常为了减轻web服务器的负载，我们把js、css、图片等静态资源分离到另一台独立域名的服务器上，在html页面中再通过相应的标签从不同域名下加载静态资源，而被浏览器允许。
添加响应头
拓展4：易于扩展？
比如有多台服务器，使用负载均衡，第一次登录转发到了A，A中seesion缓存了用户的登录信息，第二次登录转发到了B，这时候就丢失了登录状态，当然这样也是有解决方案可以共享session，但token只需要所有的服务器使用相同的解密手段即可。
拓展5：无状态？
服务端不保存客户端请求者的任何信息，客户端每次请求必须自备描述信息，通过这些信息来识别客户端身份。服务端只需要确认该token是否是自己亲自签发即可，签发和验证都在服务端进行。
拓展6：什么是单点登录？
所谓单点登录，是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
Acesss Token
访问资源接口（API）时所需要的资源凭证
简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）
特点：
服务端无状态化、可扩展性好
支持移动端设备
安全性高
支持跨程序调用
token 的身份验证流程：
客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 token
服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据
注意点：
每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
token 完全由应用管理，所以它可以避开同源策略
Refresh Token
另外一种 token——refresh token
refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。
两者区别：
Access Token 的有效期比较短，当 Acesss Token 由于过期而失效时，使用 Refresh Token 就可以获取到新的 Token，如果 Refresh Token 也失效了，用户就只能重新登录了。
Refresh Token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。
Token 的缺点
那有人就问了，既然 token 这么好，那为什么各个大公司几乎都采用共享 session 的方式呢，可能很多人是第一次听到 token，token 不香吗? token 有以下两点劣势：
token 太长了：token 是 header, payload 编码后的样式，所以一般要比 sessionId 长很多，很有可能超出 cookie 的大小限制（cookie 一般有大小限制的，如 4kb），如果你在 token 中存储的信息越长，那么 token 本身也会越长，这样的话由于你每次请求都会带上 token，对请求来是个不小的负担
不太安全：网上很多文章说 token 更安全，其实不然，细心的你可能发现了，我们说 token 是存在浏览器的，再细问，存在浏览器的哪里？既然它太长放在 cookie 里可能导致 cookie 超限，那就只好放在 local storage 里，这样会造成安全隐患，因为 local storage 这类的本地存储是可以被 JS 直接读取的，另外由上文也提到，token 一旦生成无法让其失效，必须等到其过期才行，这样的话如果服务端检测到了一个安全威胁，也无法使相关的 token 失效。
所以 token 更适合一次性的命令认证，设置一个比较短的有效期！！！
拓展：不管是 cookie 还是 token，从存储角度来看其实都不安全（实际上防护 CSRF 攻击的正确方式是用 CSRF token），都有暴露的风险，我们所说的安全更多的是强调传输中的安全，可以用 HTTPS 协议来传输， 这样的话请求头都能被加密，也就保证了传输中的安全。
其实我们把 cookie 和 token 比较本身就不合理，一个是存储方式，一个是验证方式，正确的比较应该是 session vs token。
JWT概述
JSON Web Token（简称 JWT）是目前最流行的跨域认证解决方案。是一种认证授权机制。
JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（RFC 7519）。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。
可以使用 HMAC 算法或者是 RSA 的公/私秘钥对 JWT 进行签名。因为数字签名的存在，这些传递的信息是可信的。
阮一峰老师的 JSON Web Token 入门教程 讲的非常通俗易懂，这里就不再班门弄斧了
生成 JWT
https://jwt.io/
https://www.jsonwebtoken.io/
JWT 的原理
JWT 认证流程：
用户输入用户名/密码登录，服务端认证成功后，会返回给客户端一个 JWT
客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）
当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样
服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要
因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制
JWT 的使用方式
方式一
当用户希望访问一个受保护的路由或者资源的时候，可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求头信息的 Authorization 字段里，使用 Bearer 模式添加 JWT。
用户的状态不会存储在服务端的内存中，这是一种 无状态的认证机制
服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为。
由于 JWT 是自包含的，因此减少了需要查询数据库的需要
JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务，甚至是创建一个下载流服务。
因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
方式二
跨域的时候，可以把 JWT 放在 POST 请求的数据体里。
方式三
通过 URL 传输
项目中使用 JWT
项目地址：https://github.com/yjdjiayou/jwt-demo
Token 和 JWT 的区别
相同：
都是访问资源的令牌
都可以记录用户的信息
都是使服务端无状态化
都是只有验证成功后，客户端才能访问服务端上受保护的资源
区别：
Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。
常见的前后端鉴权方式
Session-Cookie
Token 验证（包括 JWT，SSO）
OAuth2.0（开放授权）
常见的加密算法
不可逆加密：【Hash加密算法/散列算法/摘要算法】
一旦加密就不能反向解密得到密码原文，一般用来加密用户密码,app的服务器端数据库里一般存储的也都是加密后的用户密码。
在数据传输的过程中，首先把密码类数据经过MD5加密算法加密，然后再在外面使用可逆的加密方式加密一次，这样在数据传输的过程中，即便数据被截获了，但是想要完全破解，还是很难的。
Hash算法特别的地方在于它是一种单向算法，用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值，却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
用途：一般用于效验下载文件正确性，一般在网站上下载文件都能见到；存储用户敏感信息，如密码、 卡号等不可解密的信息。
常见的不可逆加密算法有：MD5、SHA、HMAC
MD5：Message Digest Algorithm MD5（中文名为消息摘要算法第五版）为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。该算法的文件号为RFC 1321（R.Rivest,MIT Laboratory for Computer Science and RSA Data Security Inc. April 1992）。MD5即Message-Digest Algorithm 5（信息-摘要算法5），用于确保信息传输完整一致。是计算机广泛使用的杂凑算法之一（又译摘要算法、哈希算法），主流编程语言普遍已有MD5实现。将数据（如汉字）运算为另一固定长度值，是杂凑算法的基础原理，MD5的前身有MD2、MD3和MD4。
MD5算法具有以下特点：1、压缩性：任意长度的数据，算出的MD5值长度都是固定的。2、容易计算：从原数据计算出MD5值很容易。3、抗修改性：对原数据进行任何改动，哪怕只修改1个字节，所得到的MD5值都有很大区别。4、强抗碰撞：已知原数据和其MD5值，想找到一个具有相同MD5值的数据（即伪造数据）是非常困难的。MD5的作用是让大容量信息在用数字签名软件签署私人密钥前被"压缩"成一种保密的格式（就是把一个任意长度的字节串变换成一定长的十六进制数字串）。除了MD5以外，其中比较有名的还有sha-1、RIPEMD以及Haval等。
SHA1 ：安全哈希算法（Secure Hash Algorithm）主要适用于数字签名标准 （Digital Signature Standard DSS）里面定义的数字签名算法（Digital Signature Algorithm DSA）。对于长度小于2^64位的消息，SHA1会产生一个160位的消息摘要。当接收到消息的时候，这个消息摘要可以用来验证数据的完整性。在传输的过程中，数据很可能会发生变化，那么这时候就会产生不同的消息摘要。SHA1有如下特点：1.不可以从消息摘要中复原信息；2.两个不同的消息不会产生同样的消息摘要,(但会有1x10 ^ 48分之一的机率出现相同的消息摘要,一般使用时忽略)。
可逆加密：可逆加密有对称加密和非对称加密。
对称加密：【文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥】
在对称加密算法中，数据发信方将明文和加密密钥一起经过特殊的加密算法处理后，使其变成复杂的加密密文发送出去，收信方收到密文后，若想解读出原文，则需要使用加密时用的密钥以及相同加密算法的逆算法对密文进行解密，才能使其回复成可读明文。在对称加密算法中，使用的密钥只有一个，收发双方都使用这个密钥，这就需要解密方事先知道加密密钥。
对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。
用途：一般用于保存用户手机号、身份证等敏感但能解密的信息。
常见的对称加密算法有AES（高级加密标准）、DES（数据加密算法）、3DES、Blowfish、IDEA、RC4、RC5、RC6
非对称加密：【两个密钥：公开密钥（publickey）和私有密钥，公有密钥加密，私有密钥解密】
非对称加密算法是一种密钥的保密方法。非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。
服务器存私钥，客户端拿公钥，客户端加解密算法可以做成so库。
非对称加密与对称加密相比，其安全性更好；非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
用途：一般用于签名和认证。
常见的非对称加密算法有：RSA（公钥加密算法）、DSA（数字签名用）、ECC（移动设备用）、Diffie-Hellman、El Gamal