安全框架知识概括

认证和授权的区别

认证和授权记忆法：

• 认证是authentication，授权是authorization
• authorization的author是作者，作者已经有了认证身份了就是作者。
• 而剩下的authen则是认证。

认证和授权简介：

• 飞机例子：
  ①你要登机，你需要出示你的身份证和机票，身份证是为了证明你张三确实是你张三，这就是 authentication；
  ②而机票是为了证明你张三确实买了票可以上飞机，这就是 authorization。
• 论坛例子：
  ①你要登陆论坛，输入用户名张三，密码1234，密码正确，证明你张三确实是张三，这就是 authentication；
  ②再一check用户张三是个版主，所以有权限加精删别人帖，这就是 authorization。

OAuth、OAuth2简介

什么是 OAuth：

• oAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 oAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此oAuth 是安全的。

什么叫第三方软件：

• 第一方就是你自已，
• 第二方就是你要解决的问题即你的对象，
• 用另外的软件去处理你的对象就是用第三方面的软件。
  ①第三方软件是针对某种软件在应用功能上的不足或者漏洞，而由非软件编制方的其他组织或个人开发的相关软件。
  ②比如我们经常玩的游戏，这些游戏的开发者就是官方，那么游戏的外挂就是第三方。
  ③这样的话，我们经常看到的一些插件就也可以理解为第三方软件了。

为什么需要 OAuth：

• 我们假设你有一个“云笔记”产品，并提供了“云笔记服务”和“云相册服务”，此时用户需要在不同的设备（PC、Android、iPhone、TV、Watch）上去访问这些“资源”（笔记，图片）

• 那么用户如何才能访问属于自己的那部分资源呢？此时传统的做法就是提供自己的账号和密码给我们的“云笔记”，登录成功后就可以获取资源了。但这样的做法会有以下几个问题：
  ①“云笔记服务”和“云相册服务”会分别部署，难道我们要分别登录吗？
  ②如果有第三方应用程序想要接入我们的“云笔记”，难道需要用户提供账号和密码给第三方应用程序，让他记录后再访问我们的资源吗？
  ③用户如何限制第三方应用程序在我们“云笔记”的授权范围和使用期限？难道把所有资料都永久暴露给它吗？
  ④如果用户修改了密码收回了权限，那么所有第三方应用程序会全部失效。
  ⑤只要有一个接入的第三方应用程序遭到破解，那么用户的密码就会泄露，后果不堪设想。

• 为了解决如上问题，oAuth 应用而生。

名词解释：

• 第三方应用程序（Third-party application）：又称之为客户端（client），比如上节中提到的设备（PC、Android、iPhone、TV、Watch），我们会在这些设备中安装我们自己研发的APP。又比如我们的产品想要使用QQ、微信等第三方登录。对我们的产品来说，QQ、微信登录是第三方登录系统。我们又需要第三方登录系统的资源（头像、昵称等）。对于QQ、微信等系统我们又是第三方应用程序。
• HTTP 服务提供商（HTTP service）： 我们的云笔记产品以及 QQ、微信等都可以称之为“服务提供商”。
• 资源所有者（Resource Owner）： 又称之为用户（user）。
• 用户代理（User Agent）： 比如浏览器，代替用户去访问这些资源。
• 认证服务器（Authorization server）： 即服务提供商专门用来处理认证的服务器，简单点说就是登录功能（验证用户的账号密码是否正确以及分配相应的权限）
• 资源服务器（Resource server）： 即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。简单点说就是资源的访问入口，比如上节中提到的“云笔记服务”和“云相册服务”都可以称之为资源服务器。

大致问题分析：

交互过程：

• oAuth 在 “客户端” 与 “服务提供商” 之间，设置了一个授权层（authorization layer）。“客户端” 不能直接登录 “服务提供商”，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。"客户端"登录授权层以后，“服务提供商” 根据令牌的权限范围和有效期，向 “客户端” 开放用户储存的资料。

OAuth 2.0授权模式概述：

• 客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。oAuth 2.0定义了四种授权方式。
  ①implicit：简化模式，不推荐使用
  ②authorization code：授权码模式
  ③resource owner password credentials：密码模式
  ④client credentials：客户端模式

简化模式：

• 简化模式适用于纯静态页面应用。所谓纯静态页面应用，也就是应用没有在服务器上执行代码的权限（通常是把代码托管在别人的服务器上），只有前端JS 代码的控制权。
• 这种场景下，应用是没有持久化存储的能力的。因此，按照 oAuth2.0 的规定，这种应用是拿不到 Refresh Token的。其整个授权流程如下：
• 该模式下，access_token 容易泄露且不可刷新

授权码模式：

• 授权码模式适用于有自己的服务器的应用，它是一个一次性的临时凭证，用来换取 access_token 和refresh_token。认证服务器提供了一个类似这样的接口：

https://www.funtl.com/exchange?code=&client_id=&client_secret=

• 需要传入 code、client_id 以及 client_secret。验证通过后，返回 access_token 和
  refresh_token。一旦换取成功，code 立即作废，不能再使用第二次。流程图如下：
  
• 这个 code 的作用是保护 token 的安全性。上一节说到，简单模式下，token 是不安全的。这是因为在第 4 步当中直接把token 返回给应用。而这一步容易被拦截、窃听。引入了 code 之后，即使攻击者能够窃取到code，但是由于他无法获得应用保存在服务器的 client_secret，因此也无法通过 code 换取 token。而第 5步，为什么不容易被拦截、窃听呢？这是因为，首先，这是一个从服务器到服务器的访问，黑客比较难捕捉到；其次，这个请求通常要求是 https的实现。即使能窃听到数据包也无法解析出内容。
• 有了这个 code，token 的安全性大大提高。因此，oAuth2.0 鼓励使用这种方式进行授权，而简单模式则是在不得已情况下才会使用。

密码模式：

• 密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向 "服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分。
• 一个典型的例子是同一个企业内部的不同产品要使用本企业的 oAuth2.0体系。在有些情况下，产品希望能够定制化授权页面。由于是同个企业，不需要向用户展示“xxx将获取以下权限”等字样并询问用户的授权意向，而只需进行用户的身份认证即可。这个时候，由具体的产品团队开发定制化的授权界面，接收用户输入账号密码，并直接传递给鉴权服务器进行授权即可。
• 有一点需要特别注意的是，在第 2 步中，认证服务器需要对客户端的身份进行验证，确保是受信任的客户端。

客户端模式：

• 如果信任关系再进一步，或者调用者是一个后端的模块，没有用户界面的时候，可以使用客户端模式。鉴权服务器直接对客户端进行身份验证，验证通过后，返回token。

JWT

JWT：

• Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。
• JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

传统的session认证：

• 我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。
• 但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

基于session认证所显露的问题：

• Session:每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
• 扩展性:用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
• CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制：

• 基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
• 流程上是这样的：
  ①用户使用用户名密码来请求服务器
  ②服务器进行验证用户的信息
  ③服务器通过验证发送给用户一个token
  ④客户端存储token，并在每次请求时附送上这个token值
  <1>token请求头Authorization中。
<2>token放在请求参数中
  ⑤服务端验证token值，并返回数据
  ⑥这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

JWT长什么样？

• JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

JWT的构成:

• 第一部分我们称它为头部（header),
• 第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，
• 第三部分是签证（signature).

header(头部):

• jwt的头部承载两部分信息：
  ①声明类型，这里是jwt
  ②声明加密的算法 通常直接使用 HMAC SHA256
  <1>HS256：一种对称加密算法，使用同一个秘钥对signature加密解密
  <2>RS256：一种非对称加密算法，使用私钥加密，公钥解密
• 完整的头部就像下面这样的JSON：

{
   
  'typ':