解析Web开发中的几种认证方法及应用场景

解析Web开发中的几种认证方法及应用

在Web开发中，认证是保障系统安全性的重要一环。不同的应用场景对认证方式的要求也不同。下面我们来详细介绍几种常见的认证方式。

本文是看了B站博主“IT老齐”的一个视频，算是一个笔记，再者星哥再去整合一些知识。

image-20250122155323565

image-20250122155323565

基本认证(Basic Auth)

image-20250122155419444

Basic Auth

HTTP Basic Authentication（基本认证） 是一种简单的身份验证方法，广泛应用于一些对安全要求不高的场景，或者作为 Web 服务、API 之间通信的基本身份验证机制。

尽管存在安全隐患，但它因其实现简洁、配置简单，仍然在很多场景中得到了应用。

在Nginx中实现 Basic Authentication

1.生成 .htpasswd 文件

使用 htpasswd 工具生成用户名和密码的组合，并加密密码。

htpasswd -c /etc/nginx/.htpasswd user1

2.配置 Nginx

在 Nginx 配置文件（通常是 /etc/nginx/nginx.conf 或相应的虚拟主机配置文件）中，添加以下配置来启用 Basic Authentication：

server {
    listen 80;
    server_name example.com;

    location / {
        auth_basic "Restricted Access";  # 提示信息
        auth_basic_user_file /etc/nginx/.htpasswd;  # 指定密码文件路径

        # 其他配置
    }
}

3.重启 Nginx

保存配置文件后，重启 Nginx 以使配置生效：

sudo systemctl restart nginx

使用浏览器打开站点，输入用户名密码

image-20250122162928935

image-20250122162928935

如果输入错误则会显示401

image-20250122163158120

image-20250122163158120

令牌认证(Token Auth)

image-20250122155523019

image-20250122155523019

什么是令牌认证

令牌认证是一种安全协议，通过使用加密令牌来验证用户的身份。与传统的用户名和密码相比，令牌认证提供了一个额外的安全层，可以更有效地保护用户的数据。

简单来说，令牌就像是一张通行证。 当你成功登录一个系统后，系统会给你颁发一个独特的令牌。这个令牌包含了你的身份信息，但它不是明文，而是经过加密的。在后续的请求中，你只需要携带这个令牌，系统就能识别你的身份，而不需要你每次都重新输入密码。

工作原理

1. 1. 用户登录： 用户输入用户名和密码进行登录。
2. 2. 服务器验证： 服务器验证用户的身份信息。
3. 3. 颁发令牌： 如果验证通过，服务器会生成一个令牌，并将其发送给客户端。
4. 4. 客户端存储： 客户端将令牌存储起来，通常存储在本地存储或cookie中。
5. 5. 后续请求： 客户端在后续的请求中将令牌包含在请求头中。
6. 6. 服务器验证令牌： 服务器验证令牌的有效性，如果验证通过，则允许用户访问资源。

常见应用场景

API接口认证： 保护API接口的安全，防止未授权访问。

单点登录： 用户只需登录一次，即可访问多个系统。

移动应用认证： 保护移动应用的数据安全。

令牌的类型

JWT（JSON Web Token）： 一种常用的令牌格式，它是一个自包含的、安全的、基于JSON的令牌。

OAuth 2.0： 一种授权框架，它允许第三方应用代表用户访问用户的资源。

SAML（Security Assertion Markup Language）： 一种基于XML的标准，用于在不同的安全域之间交换身份认证和授权数据。

JWT（JSON Web Token）

JWT (JSON Web Token) 是一种开放标准（RFC 7519），用于在网络上安全地传输信息的简洁、自包含的方式。它通常被用于身份验证和授权机制。

形象地说，JWT就像是一张通行证。当用户登录成功后，服务器会签发给用户一张通行证（即JWT），这张通行证包含了用户的一些基本信息，比如用户ID、用户名、角色等。用户在后续的请求中，只需携带这张通行证，就可以证明自己的身份，而不需要每次都重新登录。

JWT 的结构

一个 JWT 实际上是一个字符串，它由三部分组成，并用点（.）分隔：

头部（Header）： 包含了 metadata，比如 token 的类型（JWT）和所使用的签名算法。

载荷（Payload）： 包含了声明，例如，用户的 ID、用户名、以及过期时间等。

签名（Signature）： 签名是对前两部分内容的签名，用于验证消息的完整性。

image-20250122164522423

image-20250122164522423

OAuth2 Auth

image-20250122155703171

image-20250122155703171

什么是 OAuth 2.0

OAuth 2.0 是一种授权框架，允许第三方应用程序在用户授权的情况下，访问用户在其他服务提供商（如 Google、Facebook）上的受保护资源。简单来说，就是让第三方应用能够代表用户执行一些操作，而无需直接获取用户的密码。

举个例子： 当你使用微信登录一个网站时，这个网站就是第三方应用，它通过 OAuth 2.0 向微信申请授权，获取你的部分个人信息，从而让你不用重新注册就可以登录这个网站。

工作流程

1. 1. 用户授权： 用户在客户端上发起授权请求，客户端将用户重定向到授权服务器。
2. 2. 授权服务器验证： 授权服务器验证用户的身份。
3. 3. 用户同意： 用户同意授权客户端访问其资源。
4. 4. 授权服务器颁发授权码： 授权服务器颁发一个授权码给客户端。
5. 5. 客户端获取访问令牌： 客户端使用授权码向授权服务器请求访问令牌。
6. 6. 授权服务器颁发访问令牌： 授权服务器验证授权码后，颁发访问令牌给客户端。
7. 7. 客户端访问资源： 客户端使用访问令牌向资源服务器请求资源。
8. 8. 资源服务器验证： 资源服务器验证访问令牌的有效性，如果验证通过，则返回资源给客户端。

API KEY 认证

image-20250122155824722

image-20250122155824722

定义与原理

API Key就像一个专门用来开启某个“特定房间”的钥匙，这个“特定房间”就是API，一个允许两个不同应用程序交流的桥梁。它是一个唯一的字符串，用于标识和验证API的用户。

当客户端向API发送请求时，需要在请求头中包含API Key，以证明其有权访问该API。服务器端收到请求后，会验证请求头中的API Key是否与存储在服务器端的密钥副本匹配，如果匹配，则认为请求是合法的，否则请求将被拒绝。

实现步骤

API Key认证的实现通常遵循以下步骤：

1. 1. 生成API Key：服务提供者为用户生成一个唯一的API Key，这个Key需要保密，不应在网络上明文传输。
2. 2. 构建请求：客户端在发送请求时，需要在请求头或请求体中加入API Key。有时，为了增强安全性，还会结合其他信息（如请求的时间戳、请求路径等）生成一个签名，并将签名一同发送到服务器。
3. 3. 验证API Key：服务器收到请求后，会验证请求头中的API Key或签名的有效性。如果API Key匹配或签名验证通过，则认为请求是合法的，否则请求将被拒绝。

例子

比如星哥使用的图床就是某云的对象存储，在控制台中申请KeyID和KeySecret，并且赋予访问权限之后，再通过id和secret就可以访问对应的对象存储，就实现了上传图片等功能。

image-20250122170553299

image-20250122170553299

四种认证方式的对比

token-yqd

token-yqd

应用场景

image-20250122160738402

image-20250122160738402

Basic Auth应用场景

• • 内部系统或测试环境，对安全性要求不高时的快速验证。
• • 简单的web服务或API，尤其是在受信任的网络环境中。
• • 内部管理系统登录，当组织有严格的安全网络和访问控制时。

Token Auth应用场景

• • RESTfuI API，特别是那些需要高性能和无状态性的场景。
• • 移动应用和服务之间的通信，避免存储用户名和密码在客户端。
• • 单点登录(SSO)解决方案的一部分，简化跨系统访问。

OAuth Auth 应用场景

• • 社交媒体和第三方登录，如“使用Facebook/Google登录”
• • 云服务和API的访问控制，如允许特定应用访问用户存储在云中的数据。
• • 物联网(IoT)设备访问控制，确保设备安全地与云平台交互。

API KEY Auth 应用场景

• • 企业级API管理，尤其是面向合作伙伴或客户的API，便于跟踪和控制使用情况数据
• • 分析和聚合服务，客户通过API获取数据时认证。
• • 内容分发网络(CDN)和API网关，用于简单的访问控制和流量监控，
• • 第三方支付、调用天气API等

Session + Cookie 认证模式

Session + Cookie 认证模式是一种传统的 Web 应用程序身份验证方式。它通过在服务器端创建 Session（会话）来跟踪用户的状态，并在客户端存储 Session ID（会话标识符）到 Cookie 中，从而实现用户身份的验证。

工作原理

1. 1. 用户登录： 用户输入用户名和密码，服务器验证通过后，为该用户创建一个唯一的 Session。
2. 2. 生成 Session ID： 服务器生成一个 Session ID，并将该 ID 与 Session 信息关联起来。
3. 3. 设置 Cookie： 服务器将 Session ID 设置为一个 Cookie，发送给客户端。
4. 4. 客户端存储 Cookie： 客户端的浏览器会将这个 Cookie 保存起来。
5. 5. 后续请求： 每次客户端向服务器发送请求时，浏览器都会自动将这个 Cookie 发送给服务器。
6. 6. 服务器验证 Session： 服务器根据 Cookie 中的 Session ID 找到对应的 Session，验证用户身份。

优点

session信息需要额外的数据库存储，例如一般需增加redis、memached等应用。在多机负载时，需要考虑session共享；

简单易懂： 实现相对简单，易于理解。

广泛支持： 大多数 Web 服务器和编程语言都支持 Session。

状态保持： 可以方便地存储用户的状态信息，如购物车、登录状态等。

缺点

session信息统一管理，可以在服务端统一控制认证的过期时间或个别用户的过期时间。

状态维护： 服务器需要维护大量的 Session，占用服务器资源。

跨域问题： 跨域请求时，Cookie 不能自动发送，需要额外的处理。

安全性问题： Cookie 存储在客户端，容易被篡改或窃取。

负载均衡： 在分布式系统中，Session 的共享和同步比较复杂。

结尾

在Web开发中，选择合适的认证方式对于保护用户隐私和资源安全至关重要。不同的认证方式具有不同的优缺点和适用场景。因此，在开发过程中，需要根据具体需求和场景来选择合适的认证方式，并采取相应的安全措施来确保认证过程的安全性和可靠性。