API安全与认证实战从JWT到OAuth2的完整技术路线API安全的三个核心层次独立开发者的产品API一旦上线就会面临安全威胁。不是我的产品小没人攻击我——很多攻击是自动化的扫描工具Bot在扫有哪些API有常见漏洞然后批量利用。API安全分为三个层次每个层次对应不同的威胁和防御策略L1认证Authentication—— 你是谁确保来访问API的请求确实来自你声称的那个用户。如果没有认证任何人都能调用你的API包括删除数据的接口。L2授权Authorization—— 你能做什么即使确认了用户身份还需要检查这个用户是否有权限执行这个操作。比如用户A不能删除用户B的文章。L3防护Protection—— 如何防止滥用即使认证和授权都正确API仍然可能被滥用如某个用户用脚本高频调用你的API导致服务不可用。需要速率限制、输入验证、HTTPS等防护措施。L1实战JWT认证的正确实现JWTJSON Web Token是目前最流行的API认证方案。但用JWT和安全地用JWT之间有很大差距。JWT的基础流程用户登录发送邮箱密码服务器验证密码正确生成一个JWT包含用户ID、过期时间用密钥签名客户端存储JWT通常在localStorage或Cookie后续API请求客户端在Authorization头里带上JWT服务器验证JWT的签名和过期时间如果有效从JWT里解析出用户ID执行请求常见的安全陷阱与正确实现陷阱一把JWT存在localStorage里localStorage的缺点是任何在你的域名下运行的JavaScript代码都能读取它。如果你引入了有XSS漏洞的第三方脚本攻击者的代码能偷走JWT。正确做法用HttpOnly、Secure、SameSiteStrict的Cookie存储JWT。// 服务器设置Cookie的响应 res.cookie(token, jwtToken, { httpOnly: true, // JavaScript不能读取这个Cookie secure: true, // 只在HTTPS下发送 sameSite: strict, // 只在同站点请求里发送 maxAge: 7 * 24 * 60 * 60 * 1000 // 7天过期 });陷阱二JWT不过期或过期时间太长如果你设了expiresIn: 1y的JWT一旦这个JWT被偷走攻击者能在整整一年内冒充这个用户。正确做法用短期Access Token 可刷新的Refresh Token方案。Access Token过期时间短如15分钟存在内存里Refresh Token过期时间长如7天存在HttpOnlyCookie里Access Token过期后客户端用Refresh Token去换一个新的Access Token陷阱三JWT的签名密钥不够强JWT的签名密钥如果太简单如my-secret攻击者可以用暴力破解或字典攻击猜出密钥然后自己生成合法的JWT就能冒充任何用户。正确做法用足够随机的、长的密钥。# 生成一个32字节的随机密钥 openssl rand -hex 32 # 输出示例a3f9c2d8e5b1a7f4c8d2e6b9a5f3c8d1e7b5a9c3f7d5e2b8a6c4f9d1e3b7把这个密钥存在环境变量里不要硬编码在代码里const JWT_SECRET process.env.JWT_SECRET!; // 生成JWT const token jwt.sign({ userId: user.id }, JWT_SECRET, { expiresIn: 15m }); // 验证JWT try { const payload jwt.verify(token, JWT_SECRET); // payload.userId 就是用户ID } catch (error) { // Token无效或过期 throw new Error(Unauthorized); }L2实战基于角色的访问控制RBAC认证解决了你是谁授权解决你能做什么。对于独立开发者的产品最常用的授权模型是RBACRole-Based Access Control基于角色的访问控制。核心概念角色Role如admin管理员、user普通用户、guest访客权限Permission如post:create、post:delete、user:manage映射哪个角色拥有哪些权限数据库设计-- 用户表 CREATE TABLE users ( id SERIAL PRIMARY KEY, email TEXT UNIQUE, role TEXT DEFAULT user -- admin 或 user ); -- 权限表可选如果你需要很细粒度的权限控制 CREATE TABLE permissions ( id SERIAL PRIMARY KEY, role TEXT, resource TEXT, -- 如 post action TEXT -- 如 create, delete );代码实现Express.js中间件// 检查用户是否登录的中间件 function authenticate(req, res, next) { const token req.cookies[token]; if (!token) return res.status(401).json({ error: Unauthorized }); try { const payload jwt.verify(token, process.env.JWT_SECRET!); req.user { id: payload.userId, role: payload.role }; next(); } catch { return res.status(401).json({ error: Token invalid or expired }); } } // 检查用户是否有权限的中间件工厂函数模式 function authorize(requiredRole: string) { return (req, res, next) { if (req.user.role ! requiredRole req.user.role ! admin) { return res.status(403).json({ error: Forbidden }); } next(); }; } // 使用方式 app.post(/api/posts, authenticate, (req, res) { // 任何登录用户都能创建文章 }); app.delete(/api/posts/:id, authenticate, authorize(admin), (req, res) { // 只有admin能删除文章 });更细粒度的授权资源级权限RBAC解决了角色级别的权限。但有时候你需要资源级别的权限——比如用户A只能删除自己的文章不能删除别人的文章。这种场景下在具体的API端点里做检查app.delete(/api/posts/:id, authenticate, async (req, res) { const post await prisma.post.findUnique({ where: { id: req.params.id } }); if (!post) return res.status(404).json({ error: Not found }); // 检查这个文章是不是当前用户的 if (post.authorId ! req.user.id req.user.role ! admin) { return res.status(403).json({ error: Forbidden }); } await prisma.post.delete({ where: { id: req.params.id } }); res.json({ success: true }); });L3实战速率限制与输入验证即使认证和授权都正确API还需要防护滥用和恶意输入。速率限制Rate Limiting防止某个用户用脚本高频调用你的API如1秒内发1000个请求导致服务不可用或API成本暴涨如果你的API调用了付费的外部服务。实现方案用express-rate-limit库内存存储或redis多服务器共享速率限制状态。import rateLimit from express-rate-limit; // 全局速率限制每个IP地址15分钟内最多1000次请求 const globalLimiter rateLimit({ windowMs: 15 * 60 * 1000, // 15分钟 max: 1000, message: { error: Too many requests, please try again later. } }); // 登录接口的更严格限制每个IP1小时内最多5次失败尝试 const loginLimiter rateLimit({ windowMs: 60 * 60 * 1000, // 1小时 max: 5, message: { error: Too many login attempts, please try again in 1 hour. } }); app.use(globalLimiter); app.post(/api/login, loginLimiter, async (req, res) { // ... });输入验证Input Validation防止用户传入恶意输入导致的安全漏洞。如SQL注入用户输入; DROP TABLE users; --如果你的代码是直接字符串拼接SQL数据库可能被删XSS用户输入scriptalert(XSS)/script如果这段文字被其他用户看到如评论内容脚本会执行参数污染用户传入意外的参数如?isAdmintrue如果你的代码直接从查询参数里读这个值可能绕过授权正确的输入验证方式用Schema验证库如Zodimport { z } from zod; // 定义用户注册接口的预期输入格式 const registerSchema z.object({ email: z.string().email(), // 必须是有效邮箱格式 password: z.string().min(8), // 至少8位 username: z.string().min(3).max(20).regex(/^[a-zA-Z0-9_]$/) // 只允许字母数字下划线 }); app.post(/api/register, async (req, res) { try { // 验证输入 const validatedData registerSchema.parse(req.body); // 现在可以安全地使用 validatedData.email, validatedData.password... const user await createUser(validatedData); res.json(user); } catch (error) { if (error instanceof z.ZodError) { return res.status(400).json({ errors: error.errors }); } throw error; } });关键原则永远不要相信用户输入。所有输入都要验证、清理、参数化查询防止SQL注入。OAuth2与第三方登录集成最后谈一个常见需求让用户用GitHub/Google/微信登录你的产品。这需要用OAuth2协议。核心流程是用户点击用GitHub登录按钮跳转到GitHub的授权页面用户在GitHub上确认是否允许这个应用访问我的基本信息用户确认后GitHub跳回你的产品带上一个code你的后端用code去换access_token用access_token去GitHub API拿用户基本信息邮箱、用户名根据邮箱找到或创建你产品的用户账号生成JWT登录完成实战集成以GitHub OAuth为例步骤一在GitHub上注册OAuth应用登录GitHub → Settings → Developer settings → OAuth Apps → Register a new application填写Authorization callback URL如https://yourproduct.com/api/auth/github/callback获得Client ID和Client Secret步骤二后端实现OAuth流程// 1. 重定向用户到GitHub授权页面 app.get(/api/auth/github, (req, res) { const githubAuthURL https://github.com/login/oauth/authorize?client_id${process.env.GITHUB_CLIENT_ID}redirect_uri${encodeURIComponent(process.env.GITHUB_CALLBACK_URL!)}scopeuser:email; res.redirect(githubAuthURL); }); // 2. GitHub回调接口 app.get(/api/auth/github/callback, async (req, res) { const { code } req.query; // 2.1 用code换access_token const tokenResponse await fetch(https://github.com/login/oauth/access_token, { method: POST, body: JSON.stringify({ client_id: process.env.GITHUB_CLIENT_ID, client_secret: process.env.GITHUB_CLIENT_SECRET, code }), headers: { Content-Type: application/json, Accept: application/json } }); const { access_token } await tokenResponse.json(); // 2.2 用access_token拿用户信息 const userResponse await fetch(https://api.github.com/user, { headers: { Authorization: Bearer ${access_token} } }); const githubUser await userResponse.json(); // 2.3 根据邮箱找或创建用户 let user await prisma.user.findUnique({ where: { email: githubUser.email } }); if (!user) { user await prisma.user.create({ data: { email: githubUser.email, username: githubUser.login, provider: github } }); } // 2.4 生成JWT设置Cookie重定向到首页 const token jwt.sign({ userId: user.id, role: user.role }, process.env.JWT_SECRET!, { expiresIn: 7d }); res.cookie(token, token, { httpOnly: true, secure: true, sameSite: strict, maxAge: 7 * 24 * 60 * 60 * 1000 }); res.redirect(/); });安全注意事项Client Secret必须存在环境变量里不能暴露在前端代码redirect_uri必须精确匹配防止OAuth重定向绕过攻击拿到用户信息后验证这个邮箱是不是真的属于这个用户GitHub会返回已验证的邮箱但如果你用其他OAuth提供商需要验证邮箱归属结论API安全不是接个JWT就完了。它需要你理解认证、授权、防护三个层次并在每个层次上避免常见的安全陷阱。独立开发者不需要在早期就做到银行级别的安全但至少需要用HttpOnly Cookie存JWT、用Zod验证所有输入、给关键接口加速率限制——这三项是最低要求。
