丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
不出意外情况，我想这是一个绝大多数人都会混淆的问题。首先先从读音上来认识这两个名词，很多人都会把它俩的读音搞混，所以我建议你先先去查一查这两个单词到底该怎么读，他们的具体含义是什么。
说简单点就是：
稍微正式点（啰嗦点）的说法就是：
这两个一般在我们的系统中被结合在一起使用，目的就是为了保护我们系统的安全性。
Cookie有时也用其复数形式Cookies，存储类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。
Cookie特点：
Cookie是一段不超过4KB的小型文本数据，由一个名称（Name）、一个值（Value）和其它几个用于控制Cookie有效期、安全性、使用范围的可选属性组成。
Cookie主要用于下面三个目的：
Cookie应用：
下面是Cookie的一些应用案例：
在计算机中，尤其是在网络应用中，通常称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的Web页时，如果该用户还没有会话，则Web服务器将自动创建一个Session对象。当会话过期或被放弃后，服务器将终止该会话。
Session的主要作用就是通过服务端记录用户的状态。用于保持状态的基于Web服务器的方法。Session允许通过将对象存储在Web服务器的内存中在整个用户会话过程中保持任何对象。
Session的一些应用案例：
由于HTTP协议无状态的缺陷。WEB的设计者们提出了Cookie和Session两种解决机制。通过对两者的比较分析，指出了它们的区别与联系。
5.Session实例是轻量级的，所谓轻量级：是指他的创建和删除不需要消耗太多资源；
2.CORS(跨域资源共享)：Session状态使用范围的局限性，当一个用户从一个网站访问到另外一个网站时，这些Session信息并不会随之迁移过去。
3.存在Cookie的依赖性，实际上客户端的Session信息是存储在Cookie中的，如果客户端完全禁用掉了Cookie功能，也就不能享受到了Session提供的功能了。
4.每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加；
安全性相对较低；
1.Cookie捕获/重放；
2.恶意Cookies；
3.会话定置(SessionFixation)攻击；
4.跨站请求伪造（Cross-SiteRequestForgery，简称CSRF）攻击；
安全性相对较高；
1.web服务器防护；
2.主机安全防护；
3.跨站请求伪造（Cross-SiteRequestForgery，简称CSRF）攻击；
因为创建Session变量有很大的随意性，可随时调用，不需要开发者做精确地处理，所以过度使用Session变量将会导致代码可读性降低，使项目维护困难。
打个比方：浏览器就好像一个要去银行开户的人，而服务器就好比银行，这个要去银行开户的人这个时候显然没有帐号（SessionID），所以到银行后，银行工作人员问有没有帐号，他说没有，这个时候银行就会为他开通一个帐号。所以可以这么说，每次打开一个新的浏览器去请求的一个页面的时候，服务器都会认为，这是一个新的请求，他为你分配一个新的SessionID。
基于以上问题，于是有人就会思考，服务器为什么要保存这些信息呢，只让每个客户端去保存该多好？服务端只需把关好验证即可，因此在这种情况下，Token应用而生。
Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端。前端可以在每次请求的时候带上Token证明自己的合法地位。
说到Token我们不得不谈JWT，Why...
JWT是JSONWebToken的缩写，是目前最流行的跨域认证解决方案。
互联网服务离不开用户认证。一般流程是下面这样。
这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求session数据共享，每台服务器都能够读取session。
JWT的原理是，服务器认证以后，生成一个Base64URL编码后的JSON对象，发回给用户，JSON明文信息如下（后面叙述）。
以后，用户与服务端通信的时候，都要发回这个JSON对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。
服务器就不保存任何session数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。
{"sub":"1234567890","name":"chait","admin":true}注意：JWT默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。Signature（签名）首先，需要指定一个密钥（secret），这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header里面指定的签名算法（默认是HMACSHA256），按照下面的公式产生签名：
HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)算出签名以后，把Header（Base64URL编码）、Payload（Base64URL编码）、Signature三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。
前面提到，Header和Payload串型化的算法是Base64URL。
这个算法跟Base64算法基本类似，但有一些小的不同，区别如下：
JWT作为一个令牌（token），有些场合可能会放到URL（比如api.example.com/token=xxx）。Base64有三个字符+、/和=，在URL里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_。
你可以把它放在Cookie里面自动发送，但是这样不能跨域，针对跨域提供两种方案：
（1）JWT默认是不加密，但也是可以加密的。生成原始Token以后，可以用密钥再加密一次。（2）JWT不加密的情况下，不能将秘密数据写入JWT。（3）JWT不仅可以用于认证，也可以用于交换信息。有效使用JWT，可以降低服务器查询数据库的次数。（4）JWT的最大缺点是，由于服务器不保存session状态，因此无法在使用过程中废止某个token，或者更改token的权限。也就是说，一旦JWT签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。（5）JWT本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。（6）为了减少盗用，JWT不应该使用HTTP协议明码传输，要使用HTTPS协议传输。
虽然基于Token的身份验证实现的方式很多，但大致过程如下:
每一次请求都需要Token。Token应该在HTTP的头部发送从而保证了Http请求无状态。我们也需要设置服务器属性【Access-Control-Allow-Origin:*】来让服务器能接受到来自所有域的请求。
需要注意的是，在ACAO头部指定*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
执行流程如下：
执行流程说明：
当我们在程序中认证了信息并取得token之后，我们便能通过这个token做许多的事情。我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只限于该token被允许访问的数据）。