企业官网建设流程全解析

最近在评审一个前后端分离项目的登录方案时，又被问到两个看似简单的问题：项目已经全站上了HTTPS，为什么还要用JWT？反过来，接口都换成JWT鉴权了，HTTPS是不是可以省了？这两个问题放到一起，恰恰说明很多同学在搭接口安全体系时，把“传输加密”和“身份认证”这两件事混成了一谈。HTTPS和JWT，一个是管路的，一个是管人的，二者是互为补充的关系，谁也没法替代谁。

这篇文章我想把这两块内容彻底拆开来讲：先聊清楚HTTPS的加密链路是怎么建立的，再深入JWT的结构和验签流程，然后把“落地时最容易踩的坑”逐一拉出来。最后我会结合自己在一个多端项目里的实际选择，聊聊这套组合方案的收益与代价。不管你是刚接触安全刚需的前端开发、正在设计登录模块的后端，还是负责整个网关层的基础设施同学，这篇都适合你。

1. 加密与认证不是一回事：先从一次裸奔的登录请求说起

1.1 抓包工具里看到的“明文世界”

我之前在本地环境调一个老项目，还没接HTTPS。打开抓包工具，在登录接口上输入一组测试账号，提交以后那个请求体的内容几乎是“裸奔”的状态：

POST /api/login HTTP/1.1 Host: shop.example.com Content-Type: application/json { "username": "tester", "password": "123456" }

用户名、密码、甚至带在Cookie里的会话ID，全部以明文形式暴露在网络链路上。这不是什么罕见的场景，只要你连的路由器、运营商的接入节点、或者某个代理设备上装了抓包工具，就能看到同样的内容。

更麻烦的不只是“被偷看”，而是“被篡改”。我们常说的中间人攻击，本质上就是攻击者在通信链路的某一环插入自己，把客户端发给服务端的请求改掉，再转发过去。比如你想转账，请求到了中间人手里，收款账号被悄悄替换了。所以，单靠HTTP做业务，尤其是登录、支付、个人信息这类核心接口，就等于把家门钥匙挂在了门口。

1.2 HTTPS管的是通道，JWT管的是身份

明确区分两件事：

HTTPS解决的是“数据在传输过程中是否安全”。它做的事情相当于给请求内容套了一个加密信封，从发送方到接收方的整条通道都有加密保护，中途的人看不到信的内容，也改不了信的内容。

JWT解决的是“服务端如何确认当前请求者的身份”。它相当于包裹上的防伪身份标签。服务端撕下标签、验一下签名，就能确认这封信确实是“某个已登录用户”发来的，而不是随便伪造的。

我用一个快递场景来帮你记：押运车负责HTTPS，防伪标签负责JWT。押运车可以保证运输途中没人偷看，但快递到了驿站，驿站还是得看面单上的收件人信息和防伪标识，才能确认这件货是谁买的。你不可能说“我这包裹是用押运车送的，所以标签就不用看了”；也不可能说“我贴了防伪标签，所以用普通三轮车送就行”。两个环节各有各的防护目标，缺一不可。

1.3 这套组合到底适合什么样的项目

如果我今天在做一个纯服务端渲染的MVC老项目，页面都由后端模版渲染，登录态完全依赖Session和Cookie，那“Session + Cookie + HTTPS”其实已经够用。因为会话状态在服务端有全局视角，吊销和续期都方便，浏览器也会自动带Cookie。

但如果项目是前后端分离、有独立移动端App、或者服务要提供给多个业务方调用，那就需要JWT这类自包含的令牌机制。它的优点是无状态、跨端、容易水平扩展。注意我用的是“需要”，不是“必须”，因为传统Session在网关里做了集中存储以后也能支撑这类场景，只是代价会越来越大。

不少读者会有一个错觉：我上了HTTPS，登录就安全了。实际上HTTPS只保证“客户端到服务端”这段路安全，服务端依然无法知道请求到底是哪个用户发出来的。反过来，我做了JWT鉴权，却不开HTTPS，那令牌从客户端传到服务端的路上，随时可能被中间人截走。拿到令牌的人，就等于拿到了你的登录态。所以这两样东西天然是配套关系，而不是替代关系。

2. HTTPS握手一步步拆解：会话密钥是怎么在公开信道上安全建立的

2.1 为什么握手用非对称加密，数据传输却用对称加密

很多人第一次接触HTTPS都会问同一个问题：既然公钥加密、私钥解密这套非对称加密这么好用，为什么不直接用公钥加密所有数据，还要搞一个“会话密钥”出来？

核心原因是性能。以目前主流CPU的运行效率来看，对称加密算法（比如AES）处理数据的吞吐量，要比非对称加密算法（比如RSA、ECC）高出好几个数量级。如果你把一张图片、一段视频、一个几十MB的JSON响应全部用非对称加密，服务端的CPU很快就扛不住了。

所以TLS的设计非常务实：每次连接开始时，通过非对称加密协商出一个“临时会话密钥”，一旦这个密钥在两端的达成一致，后续所有业务数据都用对称加密快速收发。你可以理解成两个人先在电话里用保险柜商讨好了一个临时密码，然后接下来的所有快递都统一用这个密码锁箱，效率和安全都有了。

2.2 TLS 1.2 握手的关键环节还原

为了让你能跟着操作排查问题，我把TLS 1.2握手过程拆成几步，按实际发生的顺序走一遍：

1. ClientHello：客户端生成一个随机数，并把自己支持的加密套件列表、TLS版本号发给服务端。
2. ServerHello：服务端从列表里选一个双方都支持的加密套件，同时生成自己的随机数，一并返回给客户端。
3. Certificate：服务端把自己的证书链（服务端证书+中间CA证书）发给客户端。
4. ServerKeyExchange：在ECDHE这类密钥协商套件里，服务端还会发送自己的临时公钥参数。
5. 客户端验证证书：客户端拿到证书后，会校验证书是否可信、域名是否匹配、是否过期，如果校验通过，则继续。
6. 客户端发送ClientKeyExchange：客户端用自己的临时私钥和服务端的临时公钥，计算出一个“预主密钥”，并把它（在服务端公钥的加密保护下）发给服务端。
7. 双方各自计算会话密钥：客户端和服务端分别用两个随机数+预主密钥跑一个伪随机函数，得到完全相同的会话密钥。
8. Finished消息：双方用刚协商出来的会话密钥加密一条“握手完成”的消息，如果对方能正确解密并校验，握手就正式完成。

你会发现，整个握手过程中，真正的“秘密”只有预主密钥。它一旦被安全地交换出来，后续的加密通信就全依赖它派生出的会话密钥了。如果抓包的时候想看TLS握手详情，抓包工具里通常会显示“ClientHello”“ServerHello”“Certificate”“ClientKeyExchange”这些阶段，按这个顺序去读，很容易定位是在证书校验还是在密钥协商环节出的问题。

2.3 证书链校验与浏览器报错的常见原因

HTTPS的可信基础，不是“加密”本身，而是“证书是谁签的”。服务端证书由CA签发，CA证书又由更上层的根CA签发，形成一条信任链。浏览器里预装了根CA的证书，只要能递归信任到某一个根CA，就算这条链可信。

实际操作里最常见的情况，我用一个表格整理出来：

其中最容易让人困惑的是“浏览器能打开，但App请求报错”。浏览器内置的证书库很全，一般不会出问题；但App客户端如果用了WebView或原生网络库，证书校验依赖的是系统证书库，某些环境中机构签发的证书没有安装到设备上，就会直接校验失败。排查这类问题时，我一般会先用在线证书检测工具查一下证书链是否完整，再用openssl手动拉一遍证书链，往往比在业务代码里反复打日志快得多。

2.4 握手是开销，但不是不可控：TLS 1.3和会话恢复

每次HTTPS请求都要先做一次TCP握手，再做一次TLS握手，相比HTTP确实多了几个RTT的开销。第一次访问时用户的体感会特别明显，页面白屏时间更长。

好在这部分开销是可控的。TLS 1.3把握手压缩到了1个RTT，而且很多实现支持0-RTT的会话恢复，也就是客户端本地缓存上一次的会话票据，下次连接时直接就能发加密数据，省掉一整个往返。部署层面的常见优化还包括：在负载均衡上开启TLS会话复用、开启OCSP Stapling把证书状态查询内嵌到握手过程、用HTTP/2来合并并发请求连接。

我在实际运维中见过这样的坑：某个网关设备为了性能，把TLS会话缓存时间设得特别短，结果客户端每次请求都要重新握手，用户的平均响应时间硬生生多了几十毫秒。排查到最后不是代码问题，而是会话缓存策略问题。这类基础设施层面的参数，和业务代码一样值得列进监控和压测范围。

3. JWT三段式结构解读：令牌为什么可以自己证明自己

3.1 一长串字符拆成三段

JWT全称是JSON Web Token，结构上就是三个用点号分隔的字符串。随便拿一个实际令牌来做拆解：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFkbWluIiwiaWF0IjoxNzE5OTk5OTk5LCJleHAiOjE3MjAwMDA4OTl9.9VqkZlN8x00gur6p2LrDj2fDF2xL28BcGah6Vt2j4Uo

从左到右分别是：

• Header：令牌头，描述签名算法和令牌类型。
• Payload：载荷，存放身份声明和自定义数据。
• Signature：签名，由前两段加上密钥计算得到。

注意它们不是普通的Base64，而是Base64URL编码：把标准Base64里的+改成-，/改成_，并且去掉末尾的=。因为JWT经常会放在URL参数、HTTP头或者Cookie里，带+和/的字符容易产生歧义，URL安全的编码方式能避免这类问题。

3.2 Header和Payload里能放什么，不该放什么

Header主要就两个字段：

{ "alg": "HS256", "typ": "JWT" }

Payload是可选的“声明集合”。JWT定义了一组注册声明，最常用的有：sub（令牌主体，比如用户ID）、iss（签发者）、aud（受众）、exp（过期时间）、iat（签发时间）、jti（令牌唯一标识）。除了这些，你也可以加自定义字段，比如角色、用户类型等。

这里必须提醒一句：JWT默认只做签名，不做加密。也就是说，任何拿到令牌的人，都可以用Base64解码中间那段Payload，直接看到你放进去的所有字段。所以密码、手机号、身份证号、内部权限点等敏感信息，一个都不要放进Payload。有人会问：那我能用JWE吗？JWE是JWT的加密版本，确实可以加密内容，但它在实际项目里遇到得不多，因为引入之后调试成本会高不少。对绝大多数场景，正确做法是：Payload只放非敏感标识，比如用户ID、角色；真正的敏感数据放在服务端，需要的时候再查库。

3.3 Signature签名与验签的全过程

签名的作用，是保证令牌内容没被篡改。以最常用的HS256为例，签名生成过程是：

1. 对Header和Payload分别做Base64URL编码。
2. 用英文点号拼成“header.payload”这个字符串。
3. 用服务端保存的密钥，对这个字符串计算HMAC-SHA256。
4. 再对得到的二进制哈希做Base64URL编码，得到Signature。

服务端验签时，拿到令牌前两段，用同一个密钥重新计算签名，和令牌第三段比对。不一样，说明内容被改过；一样，则说明这段令牌确实是服务端签发的。

这里有个安全细节不可忽视：HS256是“对称签名”，签名和验签用的是同一个密钥。也就是说，谁有密钥，谁就能伪造令牌。RS256是“非对称签名”，签发方用私钥签名，校验方用公钥验签，密钥天然分离，更适合多个服务共享验签的微服务架构。

在实际项目中，我很建议在校验环节增加一个“算法白名单”判断：只允许RS256或ES256这类指定的算法进入验签流程。如果不限制，攻击者可能把Header里的算法改成HS256，然后诱导服务端用公钥作为HMAC密钥来验签，从而伪造任意身份。这是业界曝光过多次的真实攻击手法，限制算法是成本最低的防御手段。

3.4 JWT与Session对比：无状态的好处和代价

做个直白的对比：

“无状态”最吸引人的点，是扩容时不需要迁移会话。我有一个项目在切换JWT之前，每次新增一台应用节点，都要确保新节点能连上同一套Session存储，否则用户会被随机踢下线。换了JWT之后，新节点只要配好验签公钥，立刻就能接流量。但代价也同样明显：token一旦签发出去，服务端没有主动注销的能力。某个员工离职了，你无法让他的token立刻失效。所以现实项目里的妥协方案是：access token寿命设得很短，配合refresh token续期，再用黑名单机制兜底。这部分我在第5章详细展开。

4. 把JWT接入项目的完整思路：从生成到校验再到密钥管理

4.1 登录成功后怎么签发令牌

以最常见的账号密码登录为例，当用户把用户名和密码提交到服务端，服务端校验通过之后，要做的是生成两个令牌：

• accessToken：访问令牌，寿命短，通常10到30分钟。
• refreshToken：刷新令牌，寿命长，通常7到30天，只能用来换新的accessToken。

直接给一段示意代码，用的是Node.js生态里常见的JWT库写法，其他语言的API结构也类似：

const jwt = require('jsonwebtoken'); // 登录成功后的逻辑 const accessToken = jwt.sign( { sub: user.id, role: user.role, }, process.env.JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m', issuer: 'my-api', audience: 'my-app', } ); const refreshToken = jwt.sign( { sub: user.id, type: 'refresh', }, process.env.JWT_REFRESH_SECRET, { algorithm: 'HS256', expiresIn: '7d', issuer: 'my-api', audience: 'my-app', } );

注意到几个细节：签发者的名称建议用域名或固定项目名，受众也是一个固定值，这样不同环境下的令牌不会互相乱用。sub只放用户ID，不要放整个用户对象。至于用户角色这类经常变化的字段，我也不建议放进去。因为令牌一旦签发，里面的角色就是“冻结”的状态，改角色要等token过期再生效，容易造成权限延迟和误解。如果角色信息经常变，就让校验方每次按sub查库或查缓存。

4.2 校验环节的完整清单

很多项目在校验JWT时只做了一件事：验签。实际上，一个安全的校验流程至少包含这几步：

1. 确认算法在白名单内。
2. 用正确的密钥验签。
3. 校验过期时间exp，拒绝已过期的令牌。
4. 校验签发者iss、受众aud，防止别人签发的令牌被混用。
5. 提取身份标识sub，配合权限系统完成授权。

示意代码如下：

const jwt = require('jsonwebtoken'); function verifyAccessToken(token) { const payload = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'], issuer: 'my-api', audience: 'my-app', }); return payload; }

这里还有一个容易出错的地方：很多框架把令牌放在Authorization头里，格式是Bearer <token>。如果你直接拿整个字符串去验签，一定会失败。严格的做法是先判断前缀是不是Bearer，再把后面的部分提取出来。另外，不同服务之间如果共享了同一个密钥，验签时一定要注意区分环境和用途，不要让用户请求的令牌也能认作服务间调用的令牌。

4.3 密钥怎么管：环境变量、轮换与应急

密钥就是JWT体系里最核心的资产。如果签名密钥泄露，攻击者可以自己签一个有效期为100年的令牌，直接冒充任意用户。所以密钥管理的几条底线，这里必须写清楚：

• 不要硬编码在代码仓库里。用环境变量或密钥管理服务下发。
• 开发、测试、生产环境必须使用不同密钥。
• 给密钥设置轮换周期，建议至少每季度轮换一次签名密钥。
• 轮换时采用“双密钥并行”策略：新密钥用于签发，旧密钥保留一段时间的验签能力，确保存量令牌平滑过渡。

如果发生密钥泄露，我的应急处理顺序是：第一步，立刻在网关层和校验层拒绝所有旧令牌；第二步，重新生成密钥并部署到所有节点；第三步，通知前端的活跃用户重新登录；第四步，翻查访问日志，看看泄露前后有没有异常调用。

这里要特别提一下：很多人以为密钥是“永远不变”的，于是一次配完就再也不管了。我见过的一次真实事故，就是因为客户端包里的密钥被人反编译提取出来，攻击者签了一批管理员令牌，直到运维发现日志里有大量异常请求才反应过来。密钥轮换不只是安全审计的要求，它本身就是降低损失的关键手段。

5. 只有理解了边界，方案才算安全：JWT存储、刷新与攻击面分析

5.1 令牌放在哪：localStorage还是HttpOnly Cookie

这是前后端分离项目里讨论最多的一个问题，没有绝对的正确答案，只有基于攻击面的取舍。

localStorage的优点是前端读取方便，调API时取出来放到Header里就行。缺点是脚本一旦有XSS漏洞，攻击者通过注入的脚本可以直接window.localStorage.getItem("token")把令牌拿走，而且这个过程对用户完全无感。

HttpOnly Cookie的优点是浏览器不允许脚本读取，XSS攻击者拿不到令牌内容。缺点是它会让浏览器在每次请求时自动携带，容易触发CSRF风险。当然，CSRF可以用SameSite属性、自定义Header校验等方式压制，但多了一层配置工作。

我给一个比较务实的组合建议：

如果采用“access token放内存”的方案，意味着页面刷新之后内存里的token就丢了，用户需要重新走一次刷新流程。这恰恰是合理的设计：通过刷新令牌再换一个access token，用户无感续期，同时把真正长期有效的refresh token保护在Cookie里。这个模式是目前我见过的在Web端安全性和体验之间比较平衡的做法。

5.2 双令牌与刷新链：用时间来压缩暴露窗口

接入双令牌机制时，核心思路是：把“访问权限”和“续期能力”分开。就算access token被偷走，攻击者能使用的窗口只有几分钟；等它过期，攻击者手里只剩一个没用的字符串。而refresh token即使被偷走，服务端也要在刷新接口上做额外校验，比如校验sub是否存在、设备指纹是否一致、刷新令牌是否已经轮换过等，增加攻击成本。

刷新令牌还有一个常见优化：每次刷新时，服务端不仅返回新的accessToken，还会生成一个新的refreshToken，同时把旧的refreshToken标记为已用。这样就算攻击者偷到了refreshToken，在用户下一次正常刷新之后，旧refreshToken就会失效，攻击者无法持续续期。这个模式在实现时要注意：新老refreshToken要有一个短暂的共存期，避免极端情况下用户刚刷新完毕又因为并发请求被迫重新登录。

5.3 常见攻击场景和对应防护

围绕JWT，常见的攻击场景和我建议的防护手段总结如下：

我在实际项目中遇到最多的是最后一类：后端服务把请求头整包打进了日志，包括Authorization字段。排查线上问题的时候，日志平台里全是已经登录用户的token明文。这类问题不会立刻造成事故，但一旦日志平台被拖库，整个系统的登录态全没了。所以我的建议是：日志脱敏规则里，第一优先就是Authorization、Cookie、Password这类敏感字段。

5.4 无状态的双刃剑与“准无状态”实践

JWT看起来让服务端变成了“无状态”，但真实系统往往做不到彻底无状态。比如一个用户被管理员封禁，他的token在过期之前依然有效；某台设备丢失，上面的refresh token依然能换新的access token。这让运维同学很头疼。

解决思路是做一个轻量的“失效层”。用一个内存型数据库保存三类信息：

• 用户级别的token版本号：用户改密码、封禁、注销时递增版本号，验签时拿jti或sub对应的版本号校验。
• 短时黑名单：临时把某个泄露的jti拉黑，直到它自然过期。
• 刷新令牌的“已用”状态：防止refresh token被重放。

这样一来，JWT大部分时间还是无状态的，真正紧急的吊销场景留一条后路。我一般把这种方式叫“准无状态”：省掉了普通会话存储的全部开销，但保留了安全熔断的能力。

6. HTTPS与JWT配套使用的真实收益：传输安全与身份安全的合力

6.1 两条防线是怎么互相补位的

我们把一次正常登录后的API调用完整走一遍：

用户在前端页面上发起请求，HTTPS在传输层把请求内容加密，中间人即使抓到了数据包，看到的也只是密文；请求到达服务端后，网关先解密，应用层再拿到Authorization头里的JWT，用公钥验签、校验过期时间、确认sub对应的用户权限，最后返回业务数据。

在这个链路上，如果只有HTTPS没有JWT，那么任意一个能构造请求的人都可以声明自己是某个用户，服务端完全没有验证手段。如果只有JWT没有HTTPS，令牌在每次请求时都要裸奔在网络上，被截获一次就等于登录态丢失。两者各管一道防线，组合起来才能形成相对完整的安全闭环。

6.2 性能、运维和开发体验的综合权衡

HTTPS不是零成本，第一次握手多耗费的RTT在弱网环境中很明显；JWT也不是零成本，每次验签需要做签名运算，且令牌体积比Session ID大不少。一个含三个左右声明的JWT通常在200到280字节之间，放在每次请求的Header里，在网络带宽上确实比Session ID要多一点，但在现代带宽条件下这点差距基本无感。

更值得关注的是服务端存储的省心。传统Session方案下，每个在线用户都占用一份服务端内存或数据库连接；到了高并发场景，你得专门搭一套Redis集群来存Session，还要处理Session过期、淘汰策略、序列化失败等一系列问题。JWT方案把这份存储压力转移到了客户端，服务端只需要维护一个很小的黑名单或版本号存储。从整体运维复杂度来看，通常是有帮助的。

还有一个我常被问到的问题是：Service Mesh或API网关层要不要验签？我的建议是网关负责做证书终结、防盗链、速率限制这类传输层控制，JWT验证放在应用入口的中台服务里做，因为只有业务应用才清楚iss、aud和用户状态的具体含义。把验签放到网关，遇到多环境、多版本灰度时反而菜鸟难搞。

6.3 我给团队的实践建议与个人体会

如果让我根据项目形态给建议，我会这么说：

• 纯Web内部后台、用户量不大：Session + Cookie + HTTPS就够了，开发效率最高。
• 多端业务、需要水平扩展或开放API给第三方：HTTPS + JWT双令牌是最成熟的组合。
• 对安全性要求苛刻的系统（支付、金融类）：在前者基础上，JWT只做短期身份凭证，核心权限数据都要实时查库，并且强制全链路日志留痕。

我自己在一个多端项目里落地这套方案后的体会是：最大的收益不是某个单独的安全指标提升了，而是“安全逻辑终于有了清晰的边界”。传输层的责任由HTTPS和网关负责，认证层的责任由JWT和刷新策略负责，我不用再担心一个请求到底是该改加密还是改校验。出了问题，先看TLS握手是否正常，再看token验签是否有异常日志，分层次排查就能快速定位。

最后再分享一个小技巧：给每一个JWT都加上jti字段，它是令牌的唯一ID。平时它也许没什么用，但一旦需要针对某个令牌做短时拉黑、追踪泄露链路、审计单用户登录历史时，你就能拿着jti做精确管理。这比等token过期再处理要灵活得多。安全方案永远是在“体验”和“风险”之间做取舍，而提前给未来留好退路，是每个工程师都应该养成的习惯。