登录授权、TCP/IP、HTTPS

• 起源:「购物车」功能的需求，由 Netscape 浏览器开发团队打造。

• 工作机制：

  1、服务器需要客户端保存的内容，放在 Set-Cookie headers 里返回，客户端会自动保存。

  2、客户端保存的 Cookies，会在之后的所有请求里都携带进 Cookie header ⾥发回给服务器。

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

  4、客户端保存的 Cookie 在超时后会被删除、没有设置超时时间的 Cookie (称作 Session Cookie)在浏览器关闭后就会⾃动删除;另外，服务器也可以主动删除还未过期的客户端 Cookies。

  具体如下：

  比如说客户端要在Cookie里面保存一个苹果信息，先发起这个苹果的请求，如下：
      

  此时服务器收到请求之后就会给客户端一个response，然后携带一个Set-Cookie的头信息，如下：
      
      此时客户端就会将其存到Cookie当中，如下：
      

  
      此时这个存Cookie的动态做为开发者是不需要关心的，用户想再添加一个香焦到购物车时，则请求时浏览器自动会将客户端本地已经存的cookie信息带到请求头里面，如下：
      
      此时服务器收到之后，在response的cookie头中就会携带两个水果信息了，如下：
      

  然后客户端看到之后则更新cookie，如下：
      

  接着客户端想要把购买车当中的商品进行结账，则在请求时会将存在cookie中的所有信息一并自动发往服务器，如下：
     

• Cookie的作用：
  1、会话管理:登录状态、购物车。
       这里以Cookie管理登录状态为例说明一下：
       
       此时用户已经登录了，服务器就会记录其登录状态，如下：
      

  此时在reponse头中会将此sessionid放到cookie头返给客户端，如下：
      

  此时客户端就会将此cookie记录下来：

  

  此时如果客户端再次请求时则会自动将cookie带到头信息中，如下：
      
      此时服务器发现该用户已经登录了，则直接返回用户的信息给客户端，如下：
      
      如果说此时用户还想去添加购物车，则会多一个cookie信息，比如用户往购买端添加了一个苹果，如下：
      

  此时服务器在resonpse中的cookie头中就会有新的信息，如下：
      

  此时客户端自动记录新的cookie，如下：
      

  2、个性化:⽤户偏好、主题。
      这里以用户偏好为例：用户请求：
      

  此时response中返回用户的一个信息：
      

  然后存于客户端的cookie中：

  

  此时用户想访问蓝色主题了，请求信息会是如下，当然之前的cookie会自动带上去：

  

  然后服务端直接返回ok，并给用户展示蓝色的主题，如下：
      

  之后用户如果再访问其它页面，服务器就知道用户也希望是访问蓝色主题了，如下：
      

  3、Tracking:分析用户⾏为。
      这个国外用得比较多，通常在网站上会有一个类似的提示：“你正在访问的网站正在使用cookie进行网站的行踪，这个对你来说是没有害处的，而且我们一定不会将其公开，只是自己使用的，请理解”，因为有些国外法律是不允许的，必须声明一下，那具体怎么来跟踪呢，下面来大致了解一下：

  客户端请求：
      

  然后此时服务器返回的信息就有点意思了：
      

  此时客户端会记录cookie信息：
      

  接着开启请求图片了，也就是第三方的服务器，如下：
      

  接着该请求的response中也会有cookie信息下发：
      

  然后记录于客户端中：
      

  如果用户再访问了其它的网站，则就可以分析其用户上网的形为，便于投放商业广告挣钱之类的。

• HttpOnly 和 Secure 属性(了解即可)

  HttpOnly:这个 Cookie 只能⽤于 HTTP 请求，不能被 JavaScript 调用。它可以防⽌本地代码滥用Cookie。

  Secure:这个 Cookie 在⽤于请求时，只能用于安全请求(HTTPS)，不能⽤于普通的 HTTP 请求。
• XSS (Cross-site scripting)(了解即可):跨站脚本攻击。即使用 JavaScript 拿到浏览器的 Cookie 之后，发送到自⼰的⽹站，以这种⽅式来盗取⽤户 Cookie。应对⽅方式:Server 在发送 Cookie 时，敏感的 Cookie 加上 HttpOnly。
• XSRF (Cross-site request forgery)(了解即可):跨站请求伪造。即在⽤户不知情的情况下访问 已经保存了 Cookie 的⽹站，以此来越权操作⽤户账户(例如盗取用户资⾦)。应对⽅式主要是 从服务器安全⻆度考虑，就不多说了。主要是加Referer头信息，如：Referer:www.baidu.com

Basic：

Bearer【如今项目中采用的就是它】：

Bearer表示持票人，也就是持有了尚方宝剑那不就有权限了。

• 格式:Authorization: Bearer <bearer token> 
• bearer token 的获取⽅式:通过 OAuth2 的授权流程
• OAuth2 的流程【重点】:

  先来直观看一下OAuth2的授权流程，这里以掘金网（https://juejin.im/）用github的账号来登录来例，首先查看一下github账号里面有没有对掘金网进行授权，如下：
  

  然后打开掘金网点登录：
  

  

  然后此时咱们点击授权就可以正常的登录掘金了，如下：

  

  

  其上面的流程可以描述为如下步骤：

  1、第三方⽹站向授权方⽹站申请第三方授权合作，拿到 client id 和 client secret。

  2、⽤户在使用第三⽅⽹站时，点击「通过 XX (如 GitHub) 授权」按钮，第三方⽹站将⻚⾯跳

  转到授权⽅⽹站，并传入 client id 作为⾃⼰的身份标识。
  3、授权方⽹站根据 client id ，将第三⽅⽹站的信息和第三方⽹站需要的⽤户权限展示给⽤户，并询问用户是否同意授权。

  

  4、⽤户点击「同意授权」按钮后，授权方⽹站将⻚⾯跳转回第三⽅⽹站，并传入Authorization code 作为⽤户认可的凭证。

  

  5、第三⽅⽹站将 Authorization code 发送回⾃⼰的服务器。
  

  6、服务器将 Authorization code 和⾃⼰的 client secret一并发送给授权⽅的服务器，授权方服务器在验证通过后，返回 access token。OAuth 流程结束。
  

  

  

  7、在上面的过程结束之后，第三方⽹站的服务器(或者有时客户端也会)就可以使用 access token 作为用户授权的令牌，向授权方⽹站发送请求来获取⽤户信息或操作用户账户。
  

• FAQ:为什么 OAuth 要引入 Authorization code，并需要申请授权的第三⽅将 Authorization code 发送回⾃⼰的服务器，再从服务器来获取 access token，⽽不是直接返回 access token ?这样复杂的流程意义何在? 为了安全。OAuth 不强制授权流程必须使用 HTTPS，因此需要保证当通信路径中存在窃听者时，依然具有⾜够⾼的安全性。 
• 第三⽅App通过微信登录的流程，也是一个 OAuth2 流程【自已的项目中也信成了微信的登录】:
  在正式说三方登录的流程之前先得说个东东，由于三方登录比三方授权要来得晚一些，所以这里的第三方指的是微信，而非我们的网站，而上面说的三方授权的第三方的角度是不一样的，例如上面说的场景：
  
  三方是指的我们开发的网站，所以这个需要知道其概念，比较绕。下面来说一下微信的整个过程：

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

  2、用户在使用第三方 App 时，点击「通过微信登录」，第三方 App 将使用微信 SDK 跳转到微信，并传⼊⾃⼰的 client id 作为⾃⼰的身份标识。
  3、微信通过和服务器交互，拿到第三方 App 的信息，并显示在界⾯中，然后询问⽤用户是否同意授权该 App 使用微信来登录。
  4、⽤户点击「使用微信登录」后，微信和服务器交互将授权信息提交，然后跳转回第三方App，并传⼊ Authorization code 作为用户认可的凭证。
  5、第三方 App 调用⾃⼰服务器的「微信登录」Api，并传入 Authorization code，然后等待服务器的响应。
  6、服务器在收到登录请求后，拿收到的 Authorization code 去向微信的第三方授权接口发送请求，将 Authorization code 和⾃⼰的 client secret ⼀起作为参数发送，微信在验证通过后，返回 access token。
  7、服务器在收到 access token 后，⽴即拿着 access token 去向微信的用户信息接⼝发送请求，微信验证通过后，返回用户信息。
  8、服务器在收到⽤户信息后，在⾃⼰的数据库中为⽤户创建⼀个账户，并使用从微信服务器拿来的⽤户信息填入⾃⼰的数据库，以及将⽤户的 ID 和⽤户的微信 ID 做关联。
  9、用户创建完成后，服务器向客户端的请求发送响应，传送回刚创建好的⽤户信息。
  10、客户端收到服务器响应，⽤户登录成功。

• 在⾃家App中使用Bearer token

  有的 App 会在 Api 的设计中，将登录和授权设计成类似 OAuth2 的过程，但简化掉 Authorization code 概念。即:登录接口请求成功时，会返回 access token，然后客户端在之后的请求中，就可以使用这个 access token 来当做 bearer token 进行⽤户操作了。
• Refresh token
  大概服务器返回的是如下格式：
  

  ⽤法:access token 有失效时间，在它失效后，调用 refresh token 接口，传入 refresh_token 来获取新的 access token。

  ⽬的:安全。当 access token 失窃，由于它有失效时间，因此坏⼈只有较短的时间来「做坏 事」;同时，由于(在标准的 OAuth2 流程中)refresh token 永远只存在与第三方服务的服务 器中，因此 refresh token ⼏乎没有失窃的⻛险。