Cookie

起源：「购物车」功能需求

工作机制

• 1.服务器需要客户端保存的内容，放在set-cookie headers里返回，客户端会自动保存

• 2.客户端保存的cookies，会在之后的所有请求里都携带进cookie header里发送给服务器

• 3.客户端保存cookie是按照服务器域名来分类的，例如shop.com发回的cookie保存下来以后，在之后向games.com的请求中并不会携带。

• 4.客户端保存的cookie在超时后会被删除、没有设置超时时间的cookie（称作session cookie）在浏览器关闭后就会自动删除；另外，服务器也可以主动删除还未过期的客户端cookies

cookie的作用

• 会话管理：登录状态、购物车

• 个性化：用户偏好、主题

• Tracking：分析用户行为

XSS

跨站脚本攻击，即使用javascript拿到浏览器的cookie之后，发送到自己的网站，以这种方式来盗取用户cookie。

应对方式：server在发送cookie时，敏感的cookie加上HttpOnly。

CSRF/XSRF

跨站请求伪造。即在用户不知情的情况下访问已经保存了cookie的网站，以此来越权操作用户账户（例如盗取用户资金）。应对方式主要是从服务器安全角度考虑。

应对方式：Referer校验

cookie+session认证方式的缺点

1.增加请求体积，浪费性能，因为每次都会携带cookie
2. 增加服务端资源消耗，因为每个客户端连接进来都需要生成session，会占用服务端资源
3. 容易遭受CSRF攻击，即跨站请求伪造

cookie和session的区别

1. session 比 cookie 更加安全，因为它是存在服务端的，cookie 是存在客户端的。
2. cookie 只支持存储字符串数据，session 可以存储任意数据。
3. cookie 的有效期可以设置较长时间，session 有效期都比较短。
4. session 存储空间很大，cookie 有限制

cookie、sessionStorage、localStorage的区别

1. 数据存储
   cookie的数据始终在http的同源请求中存储，数据可以在客户端与服务端进行回传，webStorage的数据只能进行本地存储，不能向服务器进行传递
2. 生命周期
   sessionStorage是会话级别的缓存，当次会话结束后缓存数据被清除
   localStorage是永久缓存，直到被手动清除
   cookie可以设置生命周期，到该时间失效
3. 存储的数据量
   每次http的请求都会携带cookie，所以cookie的大小要求不能超过4k，webStorage数据因为只存储在本地，对数据存储量可以达到4-5M
4. 作用域
   sessionStorage作用在同一会话之间，不在不同浏览器窗口（标签页）共享、即使同源，cookie、localstorage在所有同源窗口之间共享
5. 应用场景
   localStoragese：适合长期保存在本地的数据。sessionStorage：敏感账号一次性登录；cookie+session 是实现认证的一种非常好的方式

Authorization

Basic

格式：Authorization：Basicusername:password(Base64ed)

http有风险，https无事

Bearer

格式：Authorization：Bearer

bearer token获取方式

通过OAuth2授权流程

0. 第三方网站向授权方网站申请第三方授权合作，拿到client id和client secret

1. 用户在使用第三方网站时，点击「通过XX（如GitHub）授权」按钮，第三方网站将跳转到授权方网站，并传入client id作为自己的身份标识

2. 授权方网站根据client ID，将第三方网站的信息和第三方需要的用户权限展示给用户，并询问是否同意授权

3. 用户点击「同意授权」按钮后，授权方网站将页面跳转回第三方网站，并传入Authorization code作为用户认证凭证。

4. 第三方网站将Authorization code发回自己的服务器

5. 服务器将Authorization code和自己的client secret（严格保密）一并发送给授权方的服务器（https），授权方服务器通过验证后，返回access token。OAuth流程结束

6. 上面的过程结束后，第三方网站服务器（或者客户端也会，客户端使用不安全，会泄漏token，这样做Authorization code的环节失去了作用 ）就可以使用access token作为用户授权令牌，向授权网站发送请求来获取用户信息或操作用户账户。但这已经在OAuth流程之外。

为什么OAuth要引入Authorization code，并需要申请授权的第三方将Authorization code发送回自己的服务器，再从服务器来获取access token，而不是直接返回access token？

为了安全。OAuth不强制授权流程必需使用https，因此需要保证当通信路径中存在窃听者时，依然具有足够高的安全性。

在自家App中使用Bearer token

有的APP在API设计中，将登录和授权设计成类似OAuth2的过程，但简化掉Authorization code的概念。
即：登录接口请求成功时，返回access token来当做bearer token进行用户操作了

第三方登录案例

第三方App通过微信登录的流程，也是一个OAuth2流程

0. 第三方App向腾讯申请第三方授权合作，拿到client id 和client secret

1. 用户在使用第三方App时点击「通过微信登录」，第三方App将使用微信SDK跳转到微信，并传入自己的client ID作为字节的身份识别

2. 微信通过和服务器交互，拿到第三方App信息，并显示在界面中，然后询问用户是否同意授权该App使用微信来登录

3. 用户点击「使用微信登录后」，微信和服务器交互将授权信息提交，然后跳回第三方APP，并传入Authorization code作为用户认可凭证。

4. 第三方APP调用自己服务器的「微信登录」api，并传入Authorization code，然后等待服务器响应。

5. 服务器在收到登录请求后，拿收到的Authorization code去向微信的第三方授权接口发送请求，将Authorization code和自己的client secret一起作为参数发送，微信验证通过后，返回access token

6. 服务器在收到access token后，立即拿着access token去向微信用户信息接口发送请求，微信验证信息通过后返回用户信息

7. 服务器在收到用户信息后，在自己的数据库中为用户创建一个账户，并使用从微信服务器拿来的用户信息填入自己的数据库，以及将用户的ID和用户的微信ID做关联

8. 用户创建完成后，服务器向客户端的请求发送响应，传送回刚创建好的用户信息

9. 客户端收到服务器响应，用户登录成功

cookie、session、token