认证授权鉴权权限控制SSO/OAuth2概念及http安全问题

一、权限概念理论

1.认证(Identification)

• 根据声明者持有的特定信息，来确认声明者的身份
• 例如身份证、用户名/密码、手机（包括短信、二维码、手势密码）、电子邮箱、生物特征（虹膜、面部、指纹、语音等）
• 高安全要求的场景下，会使用多种认证方式组合进行身份校验，即多因素认证
• 简单说就是对登录的身份认证

2.授权(Authorization)

• 资源所有者委派执行者，赋予其指定范围的权限，执行对资源的操作
• 授权实体例如银行卡、门禁卡、钥匙、证书等
• 例如web服务的session机制、浏览器的cookie机制、授权令牌token等

四个角色概念:

• 资源所有者，拥有资源的所有权利，一般就是资源的拥有者。
• 资源执行者，被委派去执行资源的相关操作。
• 操作权限，可以对资源进行的某种操作。
• 资源，有价值的信息或数据等，受到安全保护。

3.鉴权(Authentication)

• 对一个声明者的身份权利的真实性进行鉴别
• 授权和鉴权是一个一一对应的流程，有授权才会去鉴权
• 下游服务判断 权限码 是否合法

4.权限控制(Access/Permission Control)

• 将可执行的操作定义为权限列表，然后判断操作是允许/禁止
• 权限是将操作人的行为抽象化的一个概念

5.关系流程

• 这几个概念之间的关系：认证 -> 授权 -> 鉴权 -> 权限控制

• 一般情况下认证/授权同时发生，认证即授权，然后在后续行为中进行鉴权和权限控制

• 认证和鉴权的异同:

  • 认证确认的是声明者的身份，鉴权则是对声明者声明的权限进行确认
  • 认证需要通过声明者独特的信息进行识别，鉴权则是通过鉴别授权过程中定义的某个媒介，这个媒介具有真实有效、不可篡改、不可伪造等特性

• e.g. 用户的网站登录：用户在使用用户名和密码进行登录时，认证和授权两个环节一同完成，而鉴权和权限控制则发生在后续的请求访问中，比如在选购物品或支付时。

二、统一认证

1.统一认证概述

• 统一认证（Unified Authentication）是指在一个统一的认证平台下，用户通过一次身份验证即可访问多个应用系统。它通过整合不同系统的认证机制，实现跨系统的身份管理。统一认证可以提升用户体验，简化用户管理，并减少安全漏洞。

2.单点登录（SSO）

• 单点登录（Single Sign-On，SSO）是统一认证的一种实现方式。SSO允许用户在一次登录后，自动获得对所有相关应用系统的访问权限，而不需要重复登录。SSO通过中心化的认证服务来管理用户的登录状态，实现跨系统的无缝访问。
• 举个场景，假设我们的系统被切割为N个部分：商城、论坛、直播、社交…… 如果用户每访问一个模块都要登录一次，那么用户将会疯掉， 为了优化用户体验，我们急需一套机制将这N个系统的认证授权互通共享，让用户在一个系统登录之后，便可以畅通无阻的访问其它所有系统。
• 

3.优势

• 1).提升用户体验

  • 统一认证和SSO显著提升了用户体验。用户只需记住一个用户名和密码，便可以访问所有相关的应用系统，无需为每个系统单独登录。这样的便利性不仅节省了用户的时间，还减少了密码管理的困扰。
  • 

  2).降低管理成本

  • 通过统一认证，企业可以集中管理用户的身份信息和访问权限。这种集中化的管理方式降低了运维成本，并简化了用户账户的创建、更新和注销过程。管理员可以更轻松地维护用户的访问权限，确保系统的安全性和合规性。

  3).增强安全性

  • 统一认证和SSO可以提高系统的安全性。由于用户只需在一个地方输入凭据，减少了密码泄露的风险。此外，统一认证平台通常具备更强的安全措施，如多因素认证（MFA），进一步提升了系统的安全性。

  MFA介绍

  • Multi-Factor Authentication (MFA), 多重要素验证，又译多因子认证、多因素验证、多因素认证，是一种电脑访问控制的方法，用户要通过两种以上的认证机制之后，才能得到授权，使用电脑资源。例如，用户要输入PIN码，插入银行卡，最后再经指纹比对，通过这三种认证方式，才能获得授权。这种认证方式可以提高安全性。 多重要素验证的概念也广泛应用于计算机系统以外的各领域。
  • 你可能会听到它被称为 "两步验证 “或 “多因素验证”，即"Two-Step Verification” or “Multifactor Authentication”，但好的验证方式都是基于相同的原则运作。当你在一个新的设备或应用程序（如网络浏览器）上第一次登录账户时，你需要的不仅仅是用户名和密码。你需要第二个东西–我们称之为第二个 “因素”–来证明你是谁。比如，短信验证码、邮件验证码、语音、指纹、面部识别等等。

三、统一认证实现(sso)

1.sa-token sso框架

• https://sa-token.cc/doc.html#/sso/readme

2.sa-token OAuth2.0+ OIDC

• • https://sa-token.cc/doc.html#/oauth2/readme
  • https://sa-token.cc/doc.html#/oauth2/oauth2-oidc

3.SSO与OAuth2对比

• SSO是优化协同多个系统之间认证身份和授权访问。
• oauth2主要是解决：授权用户能做什么。 OIDC主要是认证用户身份。

四、OAuth2.0

1.历史由来

• 有一个第三方网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让第三方网站读取自己储存在Google上的照片
• 传统方法是，用户将自己的Google用户名和密码，告诉第三方网站，后者就可以读取用户的照片了。
• 缺点:
  • 第三方网站为了后续的服务，会保存用户的密码，这样很不安全，第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏
  • 第三方网站拥有了用户储存在Google所有资料的权力，用户没法限制第三方网站获得授权的范围和有效期
  • 用户只有修改密码，才能收回第三方网站赋予的权力
• OAuth在"客户端"与"服务提供商"之间，设置了一个授权层。“客户端"不能直接登录"服务提供商”，只能登录授权层，获取所用的令牌（token），"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

so: auth2.0更注重第三方权限的管理，适合做对外开放的授权服务。

2.OAuth 2概述

• OAuth 2（OAuth2）是一个开放标准，用于授权第三方应用程序访问用户资源，而无需共享用户凭据（如用户名和密码）。它通过向第三方应用程序颁发令牌（Token）来实现授权，从而提高了系统的安全性和用户隐私保护。

3.OAuth 2的基本概念

• 定义：OAuth 2是一个授权框架，允许第三方应用通过用户授权的形式访问服务中的用户信息。
• 作用：OAuth 2的作用是让用户授权第三方应用程序访问他们的资源，而无需共享他们的用户名和密码。
• 角色：OAuth 2定义了四种角色
  • 资源拥有者（Resource Owner）
  • 客户端（Client || 第三方应用程序）
  • 资源服务器（Resource Server
  • 授权服务器（Authorization Server）

4.OAuth 2的授权流程

1. 用户授权：用户打开第三方应用，并同意授权该应用访问其资源。
2. 请求令牌：第三方应用使用用户授权，向授权服务器请求访问令牌（Access Token）。
3. 令牌颁发：授权服务器验证用户授权后，向第三方应用颁发访问令牌。
4. 访问资源：第三方应用使用访问令牌向资源服务器请求访问用户资源。
5. 资源返回：资源服务器验证访问令牌后，向第三方应用返回请求的资源。

e.g. 微信小程序登录授权

1. 用户 点击小程序(第三方应用) 登录认证，
2. 小程序 跳转到 授权服务器(oauth2) 生成授权页面 弹出 授权请求 登录，用户判断是否授权
3. 用户授权后 授权服务器向第三方应用颁发访问令牌
   (令牌获取由第三方服务后端处理。用户授权后 授权服务器生成授权码 并携带code返回第三方后端，
   第三方后端再通过授权码向授权服务器获取令牌返回 )
4. 小程序拿到令牌后，通过携带令牌访问微信的用户信息，如昵称、头像、好友列表等(注意只能访问令牌权限范围内的信息)

e.g. 流程图

5.OAuth 2的授权模式

OAuth 2支持四种不同的授权模式，每种模式适用于不同的场景：

1. 授权码模式（Authorization Code Grant）：
   • OAuth2.0 标准授权步骤，Server 端向 Client 端下放 Code 码，Client 端再用 Code 码换取授权 Access-Token。
   • 适用于Web应用和移动应用。
   • 流程包括客户端引导用户到授权服务器进行授权，授权服务器返回授权码，客户端使用授权码向授权服务器请求访问令牌。
2. 简化模式（Implicit Grant）：
   • 无法使用授权码模式时的备用选择，Server 端使用 URL 重定向方式直接将 Access-Token 下放到 Client 端页面。
   • 适用于没有后端服务器的Web应用（如单页应用）。
   • 流程中授权服务器直接将访问令牌返回给客户端，无需通过客户端的后端服务器。
3. 密码模式（Resource Owner Password Credentials Grant）：
   • Client 端直接拿着用户的账号密码换取授权 Access-Token。
   • 适用于用户对客户端高度信任的场景，如客户端和服务器提供商是同一家公司。
   • 流程中用户直接将用户名和密码提供给客户端，客户端使用这些信息向授权服务器请求访问令牌。
4. 客户端模式（Client Credentials Grant）：
   • Server 端针对 Client 级别的 Token，代表应用自身的资源授权。
   • 适用于客户端自身需要访问授权服务器上的资源，而不是代表用户访问。
   • 流程中客户端使用自己的凭证（客户端ID和客户端密钥）向授权服务器请求访问令牌。

6.OAuth 2的优点和缺点

优点

1. 安全性：OAuth 2协议允许客户端不接触用户密码，提高了系统的安全性。
2. 广泛使用：OAuth 2是一个广泛应用的认证标准，已被许多公司和组织采用。
3. 令牌短寿命和封装：使用短寿命的访问令牌，减少了泄露和攻击的风险，并提供了灵活的令牌封装机制。
4. 资源服务器和授权服务器解耦：使得系统的结构清晰，方便不同系统之间的集成。

缺点

1. 对接流程长：使用OAuth 2进行认证和授权需要理解并实现许多概念，可能会使对接流程变得复杂和耗时。
2. 安全漏洞风险：如果使用不当，如令牌管理不善或授权过大，都可能导致安全漏洞。
3. 兼容性问题：不同的公司和组织可能会根据OAuth 2协议实现自己的认证系统，导致不同系统之间的兼容性问题。

五、HTTPS安全问题

• https://blog.youkuaiyun.com/weixin_39849054/article/details/110801422

1.cookie 和 token 都存放在 header 中，为什么不会劫持 token？

Cookie和Token都可以存放在HTTP请求的Header中进行传输，但它们有不同的机制来保护安全性，以防止劫持。

1. Cookie:
   • Cookie是一种服务器在客户端保存状态信息的机制，会在每次HTTP请求头中自动发送给服务器。
   • Cookie通常用于存储用户身份验证、会话管理等敏感信息，但Cookie的特点是每次请求都会自动携带，存在一定的安全风险。
   • 对于Cookie安全的保护，可以使用以下方法：
     • 设置Secure标志：只在HTTPS连接中传输Cookie，防止窃听攻击。
     • 设置HttpOnly标志：禁止JavaScript访问Cookie，防止XSS攻击。
     • 设置SameSite标志：限制Cookie跨站点传递，防止CSRF攻击。
2. Token:
   • Token是一种基于密钥或加密算法生成的令牌，用于身份验证和授权，常见的如JSON Web Token（JWT）。
   • Token在每次请求时需要手动添加到请求的Header中，通常使用"Authorization"字段。
   • 对于Token安全的保护，可以使用以下方法：
     • 使用HTTPS传输：通过使用加密通信的HTTPS协议，可以防止Token被拦截和窃取。
     • 仅用于授权：Token应仅用于验证用户身份和授权，而不应包含敏感数据。
     • 定期更换：定期更换Token，可以降低被劫持的风险。
3. 虽然Cookie和Token都存在一定的安全风险，但在合理使用的情况下，采取相应的安全措施可以有效地降低劫持的风险。同时，开发人员也需要注意安全编码实践，避免XSS、CSRF等攻击方式。

2.http 与 https

(1)概述

1. http
   • 安全性 是超文本传输协议，信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
   • 连接方式 http的连接很简单，是无状态的。
   • 端口不同 端口是80。
2. https
   • **安全性: ** 是具有安全性的ssl加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。
   • 连接方式 是由SSL＋HTTP协议构建的可进行加密传输、身份认证的网络协议。
   • 端口不同 端口是443。

(2)工作原理

1. http

   • 在手机或电脑进行http请求的时候，实际上是浏览器或其他应用程序将一个http的请求报文发送到了服务器。
   • 服务器收到这个请求报文之后，去处理，处理之后，返回一个响应报文。
   • 但是这个请求是怎么到达对方服务器的呢？
   • 在实际的网络中，我们的消息会经过很多的中间节点，比如我们的路由器、小区的网关等等，这些节点会以接力的形式帮我们一步步转发消息，一步步的让消息到达目标服务器。
   • 那么中间的转发者又是怎么转发这些消息的呢？
   • 如果它能够原封不动的发送到下一节点，那么一切都很顺利，但是如果它篡改了我们发送的消息呢，那不就坏事了！
     其实不只是篡改，单纯的窃听也很有风险，比如我们在发送自己的账号密码到服务器上时，路上的每一个节点都能看到，这是不是很危险？而且不只是中间节点，网络中的其他节点也是可以对消息进行监听的。
   • 所以网络从本质上就不可避免地会让别人看到我们发送和接受的信息。这个是http不安全的原因之一。但是总不能因为这个把整个网络结构改了吧？
     这就涉及到http不安全的另一个原因：明文传输

2.https

• 加密

  • https就是通过加密来让消息变得安全。https把http消息进行加密之后再传送，这样别人就算拿到之后也看不懂，这样就做到了安全！
    具体来说，https是通过对称加密、非对称加密、哈希算法共同作用来在性能和安全性上达到一个平衡。
    加密是会影响传输性能的，尤其是非对称加密，因为它的算法比较复杂。
  • HTTPS在数据传输过程中会进行两次加密：‌非对称加密和对称加密‌。
    • ‌非对称加密‌：在HTTPS连接建立的初始阶段使用，主要用于安全地交换对称加密所需的密钥。客户端和服务器各自生成一个随机数，并通过非对称加密（使用公钥加密，私钥解密）来交换这些随机数，以确保密钥交换过程中的安全性。
    • ‌对称加密‌：在密钥交换完成后，客户端和服务器使用之前通过非对称加密交换的密钥（以及它们各自生成的随机数）来生成一个会话密钥。这个会话密钥用于后续数据传输的加密和解密，因为对称加密相比非对称加密具有更高的效率。
    • 这种加密方式结合了非对称加密的安全性和对称加密的效率，确保了HTTPS连接的数据传输安全。

• 身份验证

  • 光是加密就确保安全了吗？https不仅对消息进行了加密，而且对通信对象进行了身份验证。
  • 如果我要访问www.xxx.com，需要知道我的访问对象确定是目标xxx.com而不是被拦截了网络请求然后被转移到一个其他的地址，这种拦截在http里是可以做到的，你有没有在浏览器中输入想要的网站，但是页面加载过程中突然被转移到了一个其他冒红点的其他网站，这就是被拦截到其他地址去了。
  • 但是https引入了证书机制，通过证书链可以对访问对象进行身份验证，能够保证你所访问的对象一定是你认为的那个对象。
  • 那么直接在http上实现加密、证书机制不就得了嘛？为什么还要引出一个新的https呢？毕竟一个新的东西涉及到兼容性、大众接受度、换代周期等等。

• 

• 为什么数据传输是用对称加密？

• 非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；

• 在HTTPS连接建立的初始阶段使用，主要用于安全地交换对称加密所需的密钥。客户端和服务器各自生成一个随机数，并通过非对称加密（使用公钥加密，私钥解密）来交换这些随机数，以确保密钥交换过程中的安全性。

• 为什么需要 CA 认证机构颁发证书？

• HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

• 首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的**“中间人攻击”**问题。

• 

• 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器

• 权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构

• 浏览器如何验证证书的合法性？

• 验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；

• 判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；

• 判断证书是否被篡改。需要与 CA 服务器进行校验；

• 判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率

• 只有认证机构可以生成证书吗？

• 如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问。

• 本地随机数被窃取怎么办？

• 证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的，HTTPS 如何保证随机数不会被窃取？

• 其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

• 用了 HTTPS 会被抓包吗？

• HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。

• 但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

• 既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
  HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

(3)传输模型

• . -

• 

• 四次挥手： 下图可以这么理解： 客户端：“兄弟，我这边没数据要传了，咱关闭连接吧。” 服务端：“收到，我看看我这边有木有数据了。” 服务端：“兄弟，我这边也没数据要传你了，咱可以关闭连接了。” 客户端：“好嘞。”

• 

• 建立TCP连接

• 

• 

• 

2.XSS

• Cross-site scripting的缩写，意思是“跨站脚本攻击“。攻击的原理是javaScrip可以在客户端本地拿到Cookies，并发送到自己的网站，进而盗用用户的身份信息。
• 针对这种攻击，服务器在发送“set-Cookie“时，对敏感的信息，增加”HttpOnly“修饰。它表示该Cookie只在进行HTTP请求时自动发送，不能被本地javaScrip调用。
• 它的报文格式：Set-Cookie: client_id=123;HttpOnly

3.CSRF

• Cross-site request forgery的缩写，意思是“跨站请求伪造“。它是在用户不知情的情况下，访问恶意网站，该网站使用用户Cookie向目标服务器发起请求，以此来越权操作用户的账号。
• 比如，用户登录网银，首先进入恶意网站，恶意网站使用我的Cookie来登录网银。
• 针对这种攻击，在服务器端增加“*Referer*”校验。Referer机制，是浏览器每次跳转时会强制加上，用于标记转发的网站。如果直接访问目标网址Referer为空。
• 服务器端通过只处理没有跳转的（Referer为空）请求，或者来自白名单网站转发的请求，来防范XSRF攻击。

4.https一定安全？

1. HTTPS 为什么安全？
   • 因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。
2. HTTPS 的传输过程是怎样的？
   • 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。
3. 为什么需要证书？
   • 防止”中间人“攻击，同时可以为网站提供身份证明。
4. 使用 HTTPS 会被抓包吗？
   • 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。
5. 既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
   • HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

5.越权: 水平越权&垂直越权

1. 越权

   • 权限控制功能设计存在缺陷，攻击者就可以通过这些缺陷来访问未经授权的功能或数据。基于数据的访问控制设计缺陷引起。
   • 水平越权、垂直越权

2. 水平越权

   • 权限相等者互相越权。
   • A账号和B账号都可以访问这个功能，但是A账号的个人信息和B账号的个人信息不同，可以理解为A账号和B账号个人资料这个功能上具备水平权限的划分。此时， A账号通过攻击手段访问了B账号的个人资料，这就是水平越权漏洞。

3. 垂直越权

   • 向上越权**、**向下越权。
   • 通过低级权限跨越到高级权限，用高级权限干高级权限的事情，来我们继续打比方，A是超级管理员,BC是普通用户，现在这个B啊，通过了某些手段，跨越获得了A超级管理员的权限，这就是垂直越权，垂直越权的特点就是以低级权限向高级权限跨越

4. 防范措施

   • 前后端同时对用户输入信息进行校验，双重验证机制
   • 调用功能前验证用户是否有权限调用相关功能
   • 执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
   • 直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理
   • 永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤
     • URL权限校验需要建立角色权限体系，通过过滤器
     • 在方法入口从后端Session获取用户信息
     • 在数据库操作前判断单据是否属于当前用户
     • 功能开发过程中校验业务逻辑
     • 框架层面实现ID模糊化功能

在此感谢各文献作者

文献连接:

• 认证、授权、鉴权、权限控制 喵吉诃德 https://blog.youkuaiyun.com/weixin_35016347/article/details/108776512

• 统一认证及单点登录（SSO）技术探讨 BPM_宏天低代码 https://blog.youkuaiyun.com/CC_longhua/article/details/141386590

• CAS单点登录(一)——初识SSO 逆天壁虎 https://blog.youkuaiyun.com/anumbrella/article/details/80821486

• 小白也能看懂的OAuth2讲解 问道飞鱼 https://blog.youkuaiyun.com/wendao76/article/details/142503619

• OAuth2.0 授权 & OpenID Connect 身份认证 神奇大叔 https://blog.youkuaiyun.com/weixin_43294560/article/details/131071586

• 知识点滴 - 多重验证MFA 夜流冰 https://blog.youkuaiyun.com/guoqx/article/details/123836998

• so-token 一个轻量级 Java 权限认证框架，让鉴权变得简单、优雅！ https://sa-token.cc/

  ^^^… …^^^

• 安全问题 原文 文献连接

  cookie 和 token 都存放在 header 中，为什么不会劫持 token？ 等月光倾洒 https://blog.youkuaiyun.com/rqz__/article/details/132875280

  http和https的区别是什么？ 森火123 https://blog.youkuaiyun.com/weixin_38933806/article/details/136363450

  用了 HTTPS 就一定安全吗？HTTPS 原理分析——带着疑问层层深入 Young丶 https://blog.youkuaiyun.com/agonie201218/article/details/123200092

  一文了解https为什么是安全的 python-qing https://blog.youkuaiyun.com/m0_61869253/article/details/141022015

  经得住拷问的HTTPS原理解析 程序员老舅 https://zhuanlan.zhihu.com/p/688616297

  如何防止token伪造、篡改、窃取 明月一壶酒 https://blog.youkuaiyun.com/m0_69057918/article/details/131549683

  你的 token 是安全的吗？（如何防范伪造、篡改、窃取的问题） 程序员的成长之路 https://blog.youkuaiyun.com/qq_42914528/article/details/142765611

  水平越权&垂直越权 无聊的知识 https://blog.youkuaiyun.com/weixin_54882883/article/details/125665115

  水平越权、垂直越权、防范措施 偷偷学习被我发现 https://blog.youkuaiyun.com/qq_37432174/article/details/127991485