常用的鉴权方式及它们之间的区别（JWT、Session、SSO等）

本文将从以下几个方面来讲解互联网中场景的认证、授权、鉴权、权限控制的概念及区别，以及其实际应用场景

什么是认证？

顾名思义认证其实是确定用户身份的过程。认证是指验证一个用户或者实体的身份信息，确认其是否为合法用户或实体。

常见的认证技术有哪些？

• 用户名和密码认证
• 双因素认证
• 生物特征认证，如指纹、面部识别、虹膜识别等
• 证书认证
• 单点登录（SSO）认证
• ……

什么是授权？

授权是指在用户或实体通过认证之后，确认其是否具有访问资源或执行操作的权限。授权可以基于用户角色、权限、组织机构等进行分配。在信息安全领域是指资源所有者委派执行者，赋予执行者指定范围的资源操作权限，以便对资源的相关操作。

在现实生活领域例如： 身份证（由公安局分发）、门禁卡（由物业管理处派发）、钥匙（由房东派发），这些都是现实生活中授权的实现方式。

在互联网领域例如： web 服务器的 session 机制、web 浏览器的 cookie 机制、颁发授权令牌（token）等都是一个授权的机制。

什么是鉴权？

鉴权是确认用户或实体身份及其权限的过程。是指同时进行认证和授权的过程，即确认用户或实体的身份并授予其访问资源或执行操作的权限。

什么是权限控制？

权限控制是确定如何限制用户或实体的访问权限的过程。是指在进行鉴权之后，按照一定的规则来控制用户或实体的访问权限，以确保其只能访问其被授权的资源或执行被授权的操作。

它们之间的区别和联系

在实际应用中，认证、授权、鉴权和权限控制往往是相互关联的。例如，当用户登录系统时，需要进行身份认证，然后根据用户的角色或权限确定用户能够访问的资源和操作，并进行鉴权验证，最终通过权限控制来限制用户的访问权限。

认证、授权、鉴权和权限控制是信息安全领域中不可或缺的四个概念。它们互相关联，共同构成了一个完整的安全系统。

• 认证（Authentication）：验证用户的身份，通常是通过验证用户名和密码、数字证书、生物特征等来确定用户的身份是否合法。
• 授权（Authorization）：确定用户能够访问的资源和操作，即为用户授予访问权限。
• 鉴权（Authentication）：对用户请求进行验证和授权，确定用户是否有访问资源和操作的权限。
• 权限控制（Access Control）：限制用户的访问权限，通过规定用户能够执行的操作和访问的资源来保证系统的安全性。

总的来说，认证是验证用户的身份，授权是授予用户访问权限，鉴权是对用户访问进行验证和授权，而权限控制是限制用户访问权限的控制机制。这些概念的综合应用可以实现对系统访问的安全管理和控制。

举个栗子🌰，在不同场景应用案例

这些场景可以帮助我们理解认证、授权、鉴权和权限控制之间的关系。

1.生活场景：

一个常见的生活场景是进入一个私人俱乐部，具体应用案例如下：

• 认证：在进入俱乐部之前，需要验证你的身份，例如要求出示会员卡或身份证明，以确定你是否有权限进入。
• 授权：在确定你是会员之后，工作人员需要授予你进入俱乐部的权限，例如通过扫描会员卡或者在列表中确认你的身份。
• 鉴权：在进入俱乐部之前，保安人员会对你的身份进行验证，以确保你是已经获得了授权的会员。例如，他们可能会要求你展示会员卡或者与列表中的名字相符的身份证件。
• 权限控制：进入俱乐部之后，你可能只能访问某些区域或者参加某些活动。例如，你可能只有在特定的区域内使用游泳池或使用餐厅的特定菜单。

这个场景中，认证和授权在进入俱乐部之前完成，鉴权则是在进入俱乐部前和进入俱乐部时进行的，权限控制则是进入俱乐部后进行的。这个过程中，每个步骤都是为了确保只有有权进入的会员能够进入，并且只有符合条件的会员才能够访问特定的区域和参加活动。

接下来我们再通过两个互联网场景的应用案例来深入了解下它们之间的关系

2.网站登录场景：

在网站登录场景下，用户需要进行身份认证，以确保只有经过授权的用户才能访问网站的资源。具体应用案例如下：

• 认证：用户通过输入用户名和密码进行身份认证，服务器通过校验用户提供的凭证来确定用户身份的合法性。
• 授权：通过角色和权限来控制用户能够访问的资源。例如，管理员可以访问更高级别的资源，而普通用户只能访问普通资源。
• 鉴权：对于需要特殊权限才能访问的资源，服务器需要对用户的权限进行验证，以确定用户是否有权访问该资源。
• 权限控制：管理员可以对用户的权限进行控制，例如添加/删除用户、更改用户权限等。

3.API访问控制场景：

在API访问控制场景下，需要确保只有经过授权的应用程序和用户才能访问API资源。具体应用案例如下：

• 认证：应用程序和用户通过提供合法的API密钥和令牌进行身份认证。
• 授权：应用程序和用户只能访问授权的API资源。例如，某些API可能只允许特定的应用程序或用户访问。
• 鉴权：对于需要特定权限的API资源，服务器需要对应用程序或用户的权限进行验证，以确定其是否有权访问该资源。
• 权限控制：管理员可以对应用程序和用户的访问权限进行控制，例如添加/删除应用程序、更改用户的访问权限等。

综上所述，认证、授权、鉴权和权限控制是确保应用程序和用户访问资源的安全的关键步骤。在网站登录和API访问控制场景中，这些步骤是非常重要的。

HTTP 鉴权

相关文章：你真的理解HTTP和HTTPS的区别吗？

HTTP基本鉴权框架提供了一种通过HTTP Header发送用户名/密码信息到服务器进行登录的简单身份鉴定方法。同时定义了与方法匹配的交互方式，比如鉴权失败时服务器应返回[401状态码]

Session-Cookie 鉴权

Session-Cookie 认证是利用服务端的 Session （会话）和 浏览器（客户端） 的 Cookie 来实现的前后端通信认证模式。

在理解这句话之前我们先简单了解下 什么是 Cookie 以及 什么是 Session ？

1.什么是 Cookie

众所周知，HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）；
所以为了让服务器区分不同的客户端，就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态可以通过 Cookie 去实现。

Cookie是在客户端（浏览器）保存的一段文本信息，可以包含一些用户的信息，如用户名、浏览记录、购物车等。当用户第一次访问网站时，服务器会生成一个Cookie并通过响应头的Set-Cookie字段发送给客户端，客户端在本地保存这个Cookie。当用户再次访问该网站时，浏览器会自动将该Cookie发送给服务器，服务器可以通过读取Cookie中的信息来识别用户身份、保存用户状态等。

2.什么是 Session

Session是服务器端的一种技术，用于管理和跟踪用户会话状态。当用户第一次访问网站时，服务器会为该用户创建一个Session对象，生成一个Session ID，并将Session ID保存到Cookie中发送给客户端。客户端在之后的每一次请求中都会携带该Session ID，服务器通过Session ID可以找到对应的Session对象，从而识别用户身份、保存用户状态等。

3.Session与 Cookie 的差异

总的来说，Session-Cookie 是不是就是把 Session 存储在了客户端的 Cookie 中。

Cookie是在客户端保存的一种机制，可以存储用户的一些信息；而Session是在服务器端保存的一种机制，用于管理和跟踪用户会话状态。两者可以结合使用，实现用户状态的跟踪和管理。

• 安全性： Cookie 由于保存在客户端，可随意篡改，Session 则不同存储在服务器端，无法伪造，所以 Session 的安全性更高；
• 存取值的类型不同： Cookie 只支持字符串数据，Session 可以存任意数据类型；
• 有效期不同： Cookie 可设置为长时间保持，Session 一般失效时间较短；
• 存储大小不同： Cookie 保存的数据不能超过 4K；
  

优点

• Cookie 简单易用
• 只需要后端操作即可，前端可以无感等进行操作；
• 一般中大型的网站都适用（除了 APP 移动端）；

缺点：

• 由于一般的 Session 需集中存储在内存服务器上（如 Redis），这样就会增加服务器的预算，所以预算不够请谨慎选择；
• 对移动端的支持性不友好

Token 鉴权

Token 是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。一句话概括；访问资源接口（API）时所需要的资源凭证

💡通俗点理解呢，这样一个场景：就是我们去水会时，前台发给我们一个手牌，拿到手牌后即可在场内指定区域玩乐销售。互联网交互中的token，就可以理解为水会中前台给你发的手牌。

简单token的组成；uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露）

使用token机制的身份验证方法，在服务器端不需要存储用户的登录记录。大概的流程：

1、客户端使用用户名和密码请求登录。服务端收到请求，验证用户名和密码。
2、验证成功后，服务端会生成一个token，然后把这个token发送给客户端。
3、客户端收到token后把它存储起来，可以放在cookie或者Local Storage（本地存储）里。
4、客户端每次向服务端发送请求的时候都需要带上服务端发给的token。
5、服务端收到请求，然后去验证客户端请求里面带着token，如果验证成功，就向客户端返回请求的数据。

Token 的优点：

• 服务端无状态化、可扩展性好： Token 机制在服务端不需要存储会话（Session）信息，因为 Token 自身包含了其所标识用户的相关信息，这有利于在多个服务间共享用户状态
• 支持跨程序调用： 因为 Cookie 是不允许跨域访问的，而 Token 则不存在这个问题

缺点：

• 配合： 需要前后端配合处理
• 占带宽： 正常情况下比 sid 更大，消耗更多流量，挤占更多宽带
• 性能问题： 虽说验证 Token 时不用再去访问数据库或远程服务进行权限校验，但是需要对 Token 加解密等操作，所以会更耗性能；

Token刷新机制

为了避免 Token 被盗用，一般 Token 的有效期会设置的较短，所以就有了 Refresh Token

业务接口用来鉴权的 Token，我们称之为 Access Token。
为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？

• 一种办法是：刷新 Access Token，让用户重新登录获取新 Token，会很麻烦；
• 另外一种办法是：再来一个 Token，一个专门生成 Access Token 的 Token，我们称为 Refresh Token；

Access Token： 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活；
Refresh Token： 用来获取 Access Token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 Session 一样处理；

Refresh Token 的认证流程图：

Token 和 Session-Cookie 的区别

Session-Cookie 和 Token 有很多类似的地方，但是 Token 更像是 Session-Cookie 的升级改良版。

• 存储地不同： Session 一般是存储在服务端；Token 是无状态的，一般由前端存储；
• 安全性不同： Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击；
• 支持性不同： Session-Cookie 认证需要靠浏览器的 Cookie 机制实现，如果遇到原生 NativeAPP 时这种机制就不起作用了，或是浏览器的 Cookie 存储功能被禁用，也是无法使用该认证机制实现鉴权的；而 Token 验证机制丰富了客户端类型。

JWT（JSON Web Token）鉴权

我们知道了 Token 的使用方式以及组成，我们不难发现，服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户基本信息，然后验证 Token 是否有效；这样每次请求验证都要查询数据库，增加了查库带来的延迟等性能消耗；

于是JMT来了

JWT时目前最流行的跨域身份验证解决方案

JMT的组成

JWT组成格式类似：xxxx.xxxx.xxxx的字符串，这里JWT的官网(https://jwt.io/)给出了JWT生成与验证的工具。

JWT主要由三个部分组成：头部(HEADER)，载荷(PAYLOAD)，签证(SIGNATURE)。

头部（HEADER）

typ：代表 Token 的类型，这里使用的是 JWT 类型；
alg：使用的 Hash 算法，例如 HMAC SHA256 或 RSA.

{
  "alg": "HS256",
  "typ": "JWT"
}

有效载荷（PAYLOAD）

有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。 JWT指定七个默认字段供选择。

• iss：发行人
• exp：到期时间
• sub：主题
• aud：用户
• nbf：在此之前不可用
• iat：发布时间
• jti：JWT ID用于标识该JWT

除了以上默认字段外，也可以添加自定义字段。

 {
   "sub": "1234567890",
   "name": "John Doe",
   "admin": true
 }

签名（SIGNATURE）

JWT的第三部分是一个签名信息，这个签名信息主要由三个部分组成：Header(BASE64后)，Payload(BASE64后)，secret。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)

JWT 的使用方式

其实 JWT 的认证流程与 Token 的认证流程差不多，只是不需要再单独去查询数据库查找用户用户；简要概括如下：

优点：

• 不需要在服务端保存会话信息（RESTful API 的原则之一就是无状态），所以易于应用的扩展，即信息不保存在服务端，不会存在 Session 扩展不方便的情况；
• JWT 中的 Payload 负载可以存储常用信息，用于信息交换，有效地使用 JWT，可以降低服务端查询数据库的次数

缺点：

• 加密问题： JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
• 到期问题： 由于服务器不保存 Session 状态，因此无法在使用过程中废止某个 Token，或者更改 Token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

JWT和Token的区别

• JWT令牌包含了用户的信息和权限，而Token令牌则通常只包含了一个随机生成的字符串或哈希值。
• JWT令牌通过对称或非对称加密算法进行签名和验证，使得令牌具有防伪造和篡改的能力，而Token令牌则只能依靠服务器端存储的密钥来验证。
• JWT令牌具有较长的生命周期，可以在多个客户端之间传递和共享，而Token令牌则通常只在一次请求中使用，完成验证后即被销毁。
• JWT令牌可以携带更多的元数据，如过期时间、发行者等，而Token令牌则只能用于鉴权。

单点登录（Single Sign On）

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，可以维持一段时间内的登录状态。
但随着企业的发展，一个大型系统里可能包含 n 多子系统，用户在操作不同的系统时，需要多次登录，很麻烦，那么单点登录（SSO) 就可以很好的解决这个问题的，在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

• 例如登录天猫，淘宝也会自动登录；
• 登录百度贴吧，百度网盘也会自动登录；

后续待补充…

参考文章：https://juejin.cn/post/7129298214959710244