认证的三个疑问与思考
问题一：客户端和服务端采用Cookie-Session的方式进行状态管理，服务端通过set-cookie的方式返回cookie信息，之后的客户端请求是否会自动携带cookie而无需手动填充？如果是自动填充，那么自动填充的条件是什么？
在众多的博客中，我们可以知道可以使用Cookie-Session的方式实现http连接的状态管理。具体的流程是：
- 客户端第一次发送请求给服务器。
- 服务器生成Session，然后将SessionId写入到客户端的Cookie中。
- 客户端再发送请求给服务端，header中会携带Cookie，里面携带SessionId。
- 服务端可以根据SessionId判断客户端状态。
这里我们有一个问题，就是客户端获得了Cookie，在下一次以至于之后的传输中，cookie是否都会自动携带，自动携带的条件是什么？下面是Google搜索比较多的答案，也不知道出处是哪，但是觉得有点稀里糊涂没有讲太明白。
http请求什么情况下会携带cookie
cookie与CSRF攻击
我们需要知道的是cookie有四个关键的参数
cookie各个参数及其安全性：
- Domain：访问域
- Path：路径
- Expire：过期时间
- Secure：http和https安全
在实际的开发过程中，Domain和Path这两个参数比较关键，决定了什么http请求下自动携带Token。
问题二：Cookie无法防止CSRF攻击，具体的原因是什么？
首先再来描述一下为什么Cookie无法防止CSRF攻击。
Session 认证中 Cookie 中的 SessionId 是由浏览器发送到服务端的，借助这个特性，攻击者就可以通过让用户误点攻击链接，达到攻击效果。
比如前端正常访问的服务端域名为www.a.com，误点恶意链接访问了域名www.b.com。对www.b.com的访问是不会携带cookie的，但是访问www.b.com中包含了一个对www.a.com的请求。可以这样理解：浏览器被服务器b忽悠着莫名其妙地向a发送了一个请求，这个请求并不是浏览器的本意。
不考虑一些防止CSRF攻击的解决方案，Cookie为什么会产生CSRF攻击，本质原因在于当客户端访问Cookie签发的服务器时，会自动携带Cookie，这个过程前端不需要显示处理，方便前端开发的同时，也会造成“稀里糊涂”被当枪使的安全问题。
当然Cookie是可以通过一些手段来实现防止CSRF攻击的，具体内容可以参考：
前端安全系列（二）：如何防止CSRF攻击？
问题三：一般情况下JWT存放在客户端header中的Authorization字段中，前缀为"Bearer "，这样做和cookie的本质区别是什么，cookie也是header的一个字段。
一般与Cookie-Session对比的状态管理方案就是token，具体的一个通用技术就是Json Web Token（JWT），一般情况下，服务端签发的token不存放在cookie中，而是由前端自己来存储，一般情况下存储在localStorage中。之后的每次请求，需要前端程序员编码来决定访问什么资源携带token，具体做法是从localStorage中取出token，并添加到header中的Authorization字段中。
再来考虑一下CSRF攻击，假如用户在访问a的网页中误点了一个链接，这个链接想要发送请求给a，该请求发送给服务端a时，由于没有携带token，因此被拒绝访问。
总结来说，cookie和token在CSRF攻击问题上的本质区别为，cookie会自动携带，而token需要显示添加到header中，这就保证了只有前端工程师想要访问的请求携带token。
以上内容就是我在学习认证后的一些疑问与思考，可能有理解不到位的地方，希望大家一起交流学习。
