企业官网建设流程全解析

1. 快速阅读

1.1. 为什么需要认证

没有认证的世界：

• 任何人 ──请求──▶ 服务器 ──返回──▶ 所有人的数据 ❌

有认证的世界：

• 陌生人 ──请求──▶ 服务器 ──▶ 你是谁？没有凭证，拒绝 ✅
• 合法用户 ──请求+凭证──▶ 服务器 ──▶ 验证通过，返回数据 ✅

1.2 认证方式总览

认证方式总览：

HTTP 认证方式 ├── Basic Auth （用户名+密码，最古老） ├── Bearer Token （令牌认证，最常见） │ └── JWT （自包含令牌） ├── API Key （开放平台常用） ├── OAuth 2.0 （第三方授权） ├── Session/Cookie （浏览器场景） └── HMAC 签名 （高安全场景）

各认证方式的格式对比：

安全性对比：

2. HTTP认证方式介绍

2.1 Basic Auth（基础认证）

原理：

把 "用户名:密码" 用 Base64 编码后放进请求头

格式：

用户名: admin 密码: 123456 ↓ Base64 编码 Authorization: Basic YWRtaW46MTIzNDU2 │ │ │ │ │ └─ admin:123456 编码后字符串 │ └─ 固定关键字，表示认证类型 └─ HTTP 标准请求头

流程：

客户端 服务器 │ │ │ GET /api/data │ │ Authorization: Basic xxx │ │ ────────────────────────────▶ │ │ │ Base64解码 │ │ 得到 admin:123456 │ │ 查库验证 │ 返回数据 │ │ ◀──────────────────────────── │

⚠️ 缺点：

Base64 不是加密！！ YWRtaW46MTIzNDU2 可以直接解码得到 admin:123456 所以： ❌ 不用 HTTPS 的话，密码完全裸奔 ❌ 每次请求都要带密码，泄露风险高 ❌ 无法设置过期时间 ❌ 现代项目基本不用

适用场景：

✅ 内网简单工具 ✅ 快速原型开发 ✅ 测试环境

2.2 Bearer Token（令牌认证）

原理：

用户登录后，服务器发一个"令牌" 之后每次请求带上这个令牌，而不是带密码

格式：

Authorization: Bearer <token值> │ │ │ │ │ └─ 你的 Token 字符串 │ └─ 固定关键字，表示认证类型 └─ HTTP 标准请求头 # 实际例子 #1. Token为随机字符串 # ·简单的随机字符串 # ·服务器存储对应关系 # ·不含任何信息，纯粹当"钥匙"用 Authorization: Bearer secret_abc123xyzABCXYZ456 #2.JWT（JSON Web Token） # .Token 本身包含用户信息 # .服务器无需查库，直接解码验证 # .常用于登录场景 Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.abc123 │ │ │ Header(算法) Payload(数据) Signature(签名)

流程：

客户端 服务器 │ POST /login │ │ { user: "admin", pwd: "123"} │ │ ────────────────────────────▶ │ │ │ 验证密码 │ 返回 Token │ 生成 Token │ { token: "abc123..." } │ 存储 Token │ ◀──────────────────────────── │ │ │ │ GET /api/data │ │ Authorization: Bearer abc123 │ │ ────────────────────────────▶ │ │ │ 查库验证 Token │ 返回数据 │ │ ◀──────────────────────────── │

服务器验证token流程：

收到请求 │ ▼ 提取 Authorization Header 中的 Token │ ▼ 查库：这个 Token 存在吗？ │ ├─── 不存在 → 返回 401 Unauthorized │ ▼ Token 过期了吗？ │ ├─── 过期 → 返回 401 Unauthorized │ ▼ 该 Token 有权限访问这个资源吗？ │ ├─── 无权限 → 返回 403 Forbidden │ ▼ ✅ 验证通过，返回数据

优缺点：

✅ 不用每次传密码 ✅ 可以设置过期时间 ✅ 可以随时撤销（删库中的Token） ❌ 服务器需要存储Token（有状态） ❌ Token泄露后，持有者即可访问

2.3 JWT（JSON Web Token）

原理

一种特殊的 Bearer Token Token 本身包含用户信息 服务器不需要查库，直接解码验证

格式

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36P │ │ │ Header(算法) Payload(数据) Signature(签名)

JWT的结构

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36P └─────────────────┘ └─────────────────┘ └──────────────────────────┘ Header Payload Signature （算法信息） （用户数据） （关键！防篡改）

Signature 签名是如何生成的

Signature = HMAC_SHA256( Base64(Header) + "." + Base64(Payload), 服务器密钥(SECRET_KEY) ← 只有服务器知道！ ) 【SECRET_KEY】相关知识： 1.SECRET_KEY是服务器自己配置的，通常只有一个，只有服务器自己知道(类似防伪印章) 2.SECRET_KEY 通常写在服务器的配置文件或环境变量中：JWT_SECRET_KEY=my_super_secret_key_123 3.即使黑客修改了Payload，但不知道 SECRET_KEY 无法修改Signature，最后会生成的 jwt token不能通过服务器的验证

// Header 解码后 { "alg": "HS256", // 签名算法 "typ": "JWT" } // Payload 解码后 { "userId": 123, "username": "admin", "role": "user", "exp": 1716239022 // 过期时间 } // Signature：用密钥对前两部分签名，防止篡改

流程：

客户端 服务器 │ POST /login │ │ ────────────────────────────▶ │ │ │ 验证密码 │ 返回 JWT Token │ 生成JWT（不存库） │ ◀──────────────────────────── │ │ │ │ GET /api/data │ │ Authorization: Bearer <JWT> │ │ ────────────────────────────▶ │ │ │ 解码JWT │ │ 验证签名是否合法 │ │ 检查是否过期 │ 返回数据 │ （无需查库！） │ ◀──────────────────────────── │

验证JWT流程：

收到 JWT │ ▼ 拆分三段 │ ▼ 用 SECRET_KEY 对 Header+Payload 重新计算签名 │ ├─── 签名不一致 ──▶ ❌ Token 被篡改，拒绝 │ ▼ 解码 Payload，检查 exp 过期时间 │ ├─── 已过期 ──▶ ❌ Token 过期，拒绝 │ ▼ ✅ 验证通过 从 Payload 中取出用户信息直接使用 （无需查库！）

具体例子：

• step1.服务器生成 jwt token

Header + Payload 内容： eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30 服务器密钥： my_super_secret_key_123 ↓ 经过 HMAC_SHA256 运算 生成签名： SflKxwRJSMeKKF2QT4fwpMeJf36P

• step2.服务器验证JWT token

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36P

• step2.1 拆分 Token

Header: eyJhbGciOiJIUzI1NiJ9 Payload: eyJ1c2VySWQiOjEyM30 Signature: SflKxwRJSMeKKF2QT4fwpMeJf36P ← 用户带来的签名

• step2.2 服务器自己重新计算签名

用自己存储的 SECRET_KEY 对 Header + Payload 重新运算一次 HMAC_SHA256( "eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30", "my_super_secret_key_123" ) ↓ 得到：SflKxwRJSMeKKF2QT4fwpMeJf36P ← 服务器计算出的签名

• step2.3 对比两个签名

用户带来的签名：SflKxwRJSMeKKF2QT4fwpMeJf36P 服务器计算的签名：SflKxwRJSMeKKF2QT4fwpMeJf36P ↓ 两者相同！ ✅ 验证通过，Token 合法

优缺点

✅ 服务器无需存储，无状态 ✅ 适合分布式系统（多台服务器都能验证） ✅ 可携带用户信息，减少查库 ❌ Token 无法主动撤销（只能等过期） ❌ Payload 只是 Base64 编码，不要存敏感信息 ❌ Token 越大，每次请求的体积越大

Bearer Token vs JWT

Bearer Token ← JWT 是 Bearer Token 的一种实现 普通 Bearer Token 是随机字符串 JWT 是包含信息的结构化字符串 就像： 交通工具 ← 汽车是交通工具的一种

2.4 API Key（接口密钥）

原理

平台给你分配一个固定的密钥 每次请求带上这个密钥

格式（多种携带方式）

# 方式1：放在 Header X-API-Key: sk-abc123xyz # 方式2：放在 URL 参数 GET /api/data?api_key=sk-abc123xyz # 方式3：放在 Authorization Header Authorization: Api-Key sk-abc123xyz

实际例子：

# OpenAI API Authorization: Bearer sk-proj-abc123... # 高德地图 GET /maps?key=abc123&... # 自定义Header X-API-Key: your-key-here

优缺点

✅ 简单直接，容易接入 ✅ 适合服务器之间调用 ✅ 可以针对不同Key设置不同权限 ❌ 放在URL中有泄露风险（会被记录在日志里） ❌ 长期有效，泄露风险较高 ❌ 不适合浏览器端直接使用

适用场景

✅ 开放平台（地图、天气、支付） ✅ 服务器间的 API 调用 ✅ 第三方服务集成（Notion、OpenAI）

2.5 OAuth 2.0（第三方授权）

原理

不是直接认证"你是谁" 而是"你授权我访问你在某平台的数据"

流程：最常见的"使用微信登录"场景为例

用户 你的App 微信服务器 │ │ │ │ 点击 │ │ │ "微信登录" │ │ │ ──────────▶ │ │ │ │ 跳转到微信 │ │ │ ─────────────▶ │ │ │ │ │ 微信询问：授权给该App？ │ │ ◀─────────────────────────── │ │ │ │ │ 点击确认 │ │ │ ──────────────────────────▶ │ │ │ │ 生成授权码 │ │ 返回授权码 │ │ │ ◀───────────── │ │ │ │ │ │ 用授权码换Token │ │ │ ─────────────▶ │ │ │ 返回Token │ │ │ ◀───────────── │ │ │ │ │ │ 用Token获取 │ │ │ 用户信息 │ │ │ ─────────────▶ │ │ 登录成功 │ 返回用户信息 │ │ ◀────────── │ ◀───────────── │

优缺点

✅ 不需要把密码给第三方 ✅ 可以精细控制授权范围（只读/读写） ✅ 可以随时撤销授权 ❌ 流程复杂，实现成本高 ❌ 对小项目来说过于繁重

2.6 Session / Cookie（会话认证）

原理

登录后服务器生成 Session 把 Session ID 存入 Cookie 浏览器自动携带 Cookie 发请求

流程

浏览器 服务器 │ POST /login │ │ { user, password } │ │ ────────────────────────────▶ │ │ │ 验证密码 │ │ 创建 Session │ │ 存储 Session 信息 │ Set-Cookie: sid=abc123 │ │ ◀──────────────────────────── │ │ │ │ GET /dashboard │ │ Cookie: sid=abc123 （自动） │ │ ────────────────────────────▶ │ │ │ 根据sid查Session │ 返回页面 │ 获取用户信息 │ ◀──────────────────────────── │

优缺点

✅ 浏览器自动管理，开发简单 ✅ 服务器可以主动让Session失效 ✅ 传统Web应用的标配 ❌ 服务器需要存储所有Session（有状态） ❌ 分布式部署时需要共享Session存储 ❌ 有 CSRF 攻击风险 ❌ 不适合 App / 小程序（没有Cookie机制）

2.7 HMAC 签名认证

原理

不传密码，而是用密码对请求内容进行签名 服务器用同样的方式验证签名

流程

请求参数 + 时间戳 + 密钥 │ ▼ HMAC 算法 │ 签名值 发送：请求参数 + 时间戳 + 签名值（不含密钥！）

实际例子（AWS 风格）

GET /api/data X-Timestamp: 1716239022 X-Signature: HMAC-SHA256(请求内容 + 时间戳, 密钥)

优缺点

✅ 密钥永远不在网络上传输 ✅ 防止请求被篡改 ✅ 时间戳防止重放攻击 ❌ 实现复杂 ❌ 客户端和服务器时间需要同步

适用场景

✅ 金融、支付场景（微信支付、支付宝） ✅ 高安全要求的 API ✅ AWS、阿里云等云服务 API