WEB登录认证与鉴权

一、Web的核心基础协议

1. ‌协议层级 ‌

   HTTP属于‌应用层协议‌‌，基于TCP/IP协议族实现数据传输‌12。TCP作为传输层协议，负责建立可靠连接并确保数据完整性‌。

2. ‌通信机制‌

   • 采用‌客户端-服务器架构‌，客户端（如浏览器）通过URL向服务器发送请求，服务器返回响应内容‌。
   • 定义了标准化的请求方法（如GET、POST）和报文格式（请求报文、响应报文），以避免通信歧义‌。

3. ‌技术关联 ‌

   HTTP常与HTML（超文本标记语言）协同工作，前者负责通信，后者负责内容呈现‌。例如，HTTP传输的HTML文件在客户端被解析为可视化网页‌。

4. ‌端口与无状态性‌

   • 默认使用‌80端口‌进行通信‌。
   • 属于‌无状态协议‌，每个请求独立处理，不保留之前交互的信息‌。

其他相关协议如TCP/IP是HTTP的底层支撑，但HTTP直接定义了Web服务的交互标准‌，由于HTTP协议是无状态的，每个请求都是完全独立的，所以服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。这就决定了身份识别需要客户端和服务端配合才能完成。引出下面的用户身份认证的几种方式。

二、Web用户认证方案

用户在浏览器中访问某一服务端，而服务端资源基本都会有相应的访问权限，提供给不同的用户以提供差异化服务，用户访问设限资源时首先会进行登录校验，登录校验指的是在服务器接收到浏览器发送过来的请求之后，首先要对这个请求进行校验，先要校验一下用户登录了没有。如果登录则可以接着跟该网站交互，用户可以访问已对其授权的资源，直到用户停止访问。这个过程也被称为会话。

怎么来实现登录校验的操作呢？具体的实现思路可以分为两部分：

1.在员工登录成功后，需要将用户登录成功的信息存起来，记录用户已经登录成功的标记。

2.在浏览器发起请求时，需要在服务端进行统一拦截，拦截后进行登录校验。

Cookie（客户端会话跟踪技术）【传统】

这种用户认证方案是基于cookie的，也就是数据存储在客户端浏览器当中(用户信息）， 服务器端在给客户端在响应数据的时候，会自动的将 cookie 响应给浏览器，浏览器接收到响应回来的 cookie 之后，会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求当中，都会将浏览器本地所存储的 cookie 自动地携带到服务端。

Cookie是由服务器发送给用户浏览器的小型文本文件，存储在客户端的浏览器中。它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。服务器可以读取Cookie并使用其中的信息来进行识别和个性化处理。

每个cookie都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的。cookie是不可跨域的，并且每个域名下面的Cookie的数量也是有限的。

• 优点：

HTTP协议中支持的技术

• 缺点：

1. 移动端APP无法使用Cookie
2. 不安全，用户可以自己禁用Cookie
3. Cookie不能跨域

Session（服务端会话跟踪技术）【传统】

Session是在服务器端创建和管理的一种会话机制。当用户首次访问网站时，服务器会为该用户创建一个唯一的Session ID，通常通过Cookie在客户端进行存储。会话标识符在后续的请求中用于标识具体是哪个用户。通常情况下，session 是基于cookie 实现的，session存储在服务器端sessionld 会被存储到客户端的cookie中。

传统方式对比：

1.存储位置不同：Session是存储在服务器端的，Cookie是存储在客户端的。

2.安全性不同：因为Session存储在服务器端，所以Session 比 Cookie安全。

3.存取值的类型不同：Cookie只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session可以存任意数据类型。

4.有效期不同：Cookie可设置为长时间保持，比如我们经常使用的默认登录功能，Session

一般失效时间较短，客户端关闭（默认情况下）或者Session超时都会失效。

5.存储大小不同：单个Cookie保存的数据不能超过4K，Session可存储数据远高于

Cookie，但是当访问量过多，会占用过多的服务器资源。

有了cookie和session之后，基本可以实现用户的各种验证、鉴权及身份识别了。但是，还是有一些场景中，不是特别适合这两种方案，或者说这两种方案的话还不够，那么就需要令牌技术(token)上场了。

令牌技术

如果通过令牌技术来跟踪会话，我们就可以在浏览器发起请求。在请求登录接口的时候，如果登录成功，我就可以生成一个令牌，令牌就是用户的合法身份凭证。接下来我在响应数据的时候，我就可以直接将令牌响应给前端。接下来我们在前端程序当中接收到令牌之后，就需要将这个令牌存储起来。这个存储可以存储在 cookie 当中，也可以存储在其他的存储空间(比如：localStorage)当中。

在后续的每一次请求当中，都需要将令牌携带到服务端。携带到服务端之后，接下来我们就需要校验令牌的有效性。如果令牌是有效的，就说明用户已经执行了登录操作，如果令牌是无效的，就说明用户之前并未执行登录操作。此时，如果是在同一次会话的多次请求之间，我们想共享数据，我们就可以将共享的数据存储在令牌当中就可以了。

​

jwt就是一个简单的字符串。可以在请求参数或者是请求头当中直接传递，看似是一个随机的字符串，但是我们是可以根据自身的需求在jwt令牌中存储自定义的数据内容。如：可以直接在jwt令牌中存储用户的相关信息。简单来讲，jwt就是将原始的json数据格式进行了安全的封装，这样就可以直接基于jwt在通信双方安全的进行信息传输了。

主要由以下几个场景:

1、跨域请求：Cookie是不支持跨域的，当在不同的域名之间进行通信时，使用Token可以更方便地在跨域请求中传递身份验证信息，而不受Cookie限制。

2、分布式场景：Session是存储在服务器上的，但是随着现在很多都是集群部署，这就使得Session也需要实现分布式Session，而如果能用Token的话，就可以不用这么复杂。

3、API交互：当我们使用浏览器访问后端服务的时候，可以用cookie和session，但是如果是API调用，比如Dubbo交互，就没办法做cookie的存储和传递了，而使用Token是常见的身份验证方式。客户端通过提供Token来证明其身份，并获得对受保护资源的访问权限。

4、跨平台应用程序：Token可以轻松地在不同的平台和设备之间共享和传递，而无需依赖特定的会话机制或Cookie支持。

5、前后端分离项目：现在很多项目都是前后端分离的了，这种项目中，前端和后端之间通过API的方式交互，这种的话用Token也会更加方便一些。总之，因为Cookie和Session存在各种限制，所以Token也是目前常见的身份验证和状态管理方式，它具有更大的灵活性和适用性，特别适用于现代的应用程序架构和需求。它提供了一种无状态、可扩展和安全的身份验证和授权机制。而且，有了token之后，还可以基于Token做防重检测。

CAS---Central Authentication Service(中央认证服务)

CAS是耶鲁大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法。CAS 是实现 SSO 的具体开源协议 / 框架。它提供了一套标准化的流程和工具，帮助开发者快速实现 SSO。

Central AuthService，也就是认证中心服务，多个需要实现单点登录的系统，都接入这

个统一的认证中心，所有的登录、认证都通过这个认证中心来实现。

1、用户访问子系统时重定向到CAS服务器登录。

2、CAS服务器验证用户身份并返回一个票据(Ticket）。

3、子系统使用票据向CAS验证，获取用户信息。

这个方案一般适合于企业内部做集成，可以让业务系统不再关心登录、授权，而是只关注业务逻辑，只需要做一次接入就行了。比如说你们公司的很多内部平台之间，就可能是用了同一个登录服务。可以降低接入成本低。

OAuth（Open Authorization）

它是一个关于授权（authorization）的开放网络标准，允许用户授权第三方 应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他 们数据的所有内容。OAuth在全世界得到广泛应用，目前的版本是2.0版。

协议特点

• 安全：没有涉及到用户密钥等信息，更安全更灵活；
• 开放：任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth；

应用场景

• 原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、 请求后台数据。
• 前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证
• 第三方应用授权登录，比如QQ，微博，微信的授权登录。

运行流程

OAuth 2.0的运行流程如下图，摘自RFC 6749。

（A）用户打开客户端以后，客户端要求用户给予授权。 （B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。 （D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。 （F）资源服务器确认令牌无误，同意向客户端开放资源。

下面是一个简单的示例说明：

客户端（Client）：第三方应用程序，如浏览器、APP 等，希望访问一些特定的数据。

资源服务器（Resource Server）：存储资源所有者的数据，并响应客户端的请求（如 API）。一般是指提供服务的后端服务器。

授权服务器（OAuth Server）：负责验证资源所有者的身份并颁发令牌（Access Token）。

大致流程：客户端先向授权服务器请求权限，权限校验通过后，授权服务器向客户端颁发 Access Token；后续客户端访问资源服务器时携带该令牌，资源服务器验证 Access Token，通过后返回数据。

OAuth2 的优点：

1. 安全性：用户无需向第三方应用提供密码，降低泄露风险。
2. 灵活性：通过 Scope 定义访问权限范围。
3. 普遍适用性：支持 Web 应用、移动应用、服务器端等多种客户端。

OAuth2 的缺点：

1. 实现复杂：授权流程和令牌管理机制较复杂。
2. 令牌保护：Access Token 暴露可能被滥用，需结合 HTTPS、短时效性等机制加强安全。
3. 授权服务器依赖：安全性依赖授权服务器的正确配置。