JWT用户登录注册系统PHP教程

本文深入讲解了如何在PHP中安全实现基于JWT的用户登录注册系统，涵盖密码哈希（强调必须使用password_hash()而非MD5/SHA1、避免手动加盐和截断）、JWT标准生成（推荐firebase/php-jwt库、密钥从环境变量读取、合理设置iat/exp）、严格验证流程（签名校验+过期检查+数据库二次确认用户状态）以及安全存储方案（优先采用httpOnly Cookie配合CSRF防护，而非易受XSS攻击的localStorage），同时指出常见致命误区——如硬编码密钥、明文存储敏感权限、忽略token不可撤销性等，为开发者提供一套兼顾安全性、合规性与可维护性的实战指南。

PHP注册时如何安全哈希密码并存入数据库

直接用 password_hash()，别碰 md5() 或 sha1() —— 这些不是加密，是自毁。PHP 默认的 PASSWORD_ARGON2I（PHP 7.2+）或 PASSWORD_DEFAULT（推荐，会随 PHP 升级自动切换更安全算法）已足够。

常见错误：手动拼接 salt、用 base64_encode() 伪装成“加密”、或把哈希结果截断存储导致验证失败。

• 注册流程中，对用户提交的明文密码调用 password_hash($password, PASSWORD_DEFAULT)，原样存进数据库 password 字段（确保字段长度 ≥ 255，VARCHAR(255) 是安全下限）
• 不要校验密码强度再入库——前端提示即可，后端只管哈希；真正要拦的是空密码、超长输入（如 > 1024 字符），防止 DoS 或日志污染
• 如果必须兼容老系统（比如旧密码用 bcrypt），验证时用 password_verify()，它能自动识别哈希头并匹配对应算法，不用自己判断格式

登录成功后怎么生成标准 JWT 并返回给前端

JWT 不是“自己拼字符串 + base64”，得用成熟库，否则极易漏掉签名验证、过期检查、密钥泄露等关键点。推荐 firebase/php-jwt（Composer 安装），它严格遵循 RFC 7519。

容易踩的坑：把私钥硬编码在代码里、用时间戳做 iat 却没设 exp、把敏感字段（如角色权限）明文塞进 payload 还不加密。

• 生成前先确认用户凭证有效（查库 + password_verify()），再构造 payload：['user_id' => $id, 'email' => $email, 'iat' => time(), 'exp' => time() + 3600]
• 签名密钥必须从环境变量读取（如 $_ENV['JWT_SECRET']），绝不能写死；开发环境可用 openssl rand -base64 32 生成一次性的随机密钥
• Header 固定用 ['alg' => 'HS256', 'typ' => 'JWT']，别乱改 alg——PHP-JWT 对 RS256 支持需额外配 OpenSSL 私钥，新手易卡在 pem 格式或权限上
• 返回时用 header('Content-Type: application/json') + echo json_encode(['token' => $jwt])，别混用 setcookie() 或 session 存 token

API 接口如何验证 JWT 并提取用户身份

每次请求都必须验证 token 合法性，不能“前端传了就信”。核心是三步：解析 header/payload、校验签名、检查 exp 和 nbf（如有）。

典型错误：只解码不验证签名（JWT::decode() 必须传密钥）、忽略 exp 导致永不过期、把 payload 当可信输入直接用于 SQL 查询（仍需过滤/绑定参数）。

• 用 try { $decoded = JWT::decode($token, $secret, ['HS256']); } 包裹，捕获 DomainException（签名错）、InvalidArgumentException（格式错）、UnexpectedValueException（过期或未生效）
• 验证通过后，$decoded->user_id 才可作为当前用户标识；别直接用 $decoded->email 做权限判断——数据库查一遍用户状态（是否禁用、角色变更）更稳妥
• 如果接口需要区分“登录态”和“管理员态”，权限逻辑必须在验证 JWT 后单独查库，而不是全塞进 token——JWT 一旦签发就不可撤销，靠它存动态权限等于埋雷

为什么不能把 JWT 存在 localStorage 而要配合 httpOnly Cookie

localStorage 的 token 会被 XSS 直接盗走，且无法被服务端主动失效。httpOnly Cookie + CSRF Token 组合才是 Web 应用的事实标准。

开发者常误以为“前后端分离就必须 localStorage”，其实只是没配好 Cookie 属性。

• 登录成功后，用 setcookie('token', $jwt, ['expires' => time() + 3600, 'path' => '/', 'domain' => '', 'secure' => true, 'httponly' => true, 'samesite' => 'Strict']) 下发（注意：本地开发 secure 要关掉，否则 Chrome 拒绝写入）
• 前端发起 API 请求时，浏览器自动带上 Cookie；服务端从 $_COOKIE['token'] 读取，不再依赖 Authorization Header
• CSRF 防御靠框架（如 Laravel 的 @csrf）或手动在表单放隐藏域 + 后端比对 $_POST['csrf_token'] 与 session 中存储的值；JWT 本身不解决 CSRF

JWT 的 payload 天然不适合存大量数据，超过 1KB 就会影响 HTTP 头大小和移动端首屏加载。真要传用户权限列表，宁可在验证后查一次数据库，也别往 token 里硬塞。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。