← 博客 · 2026-09-13 · ChengYoung · 约 6 分钟阅读

为什么我不把授权密钥放在第三方服务器

授权密钥是客户资产。以下是我选择「离线优先」授权设计的理由——以及它诚实的代价。

一句话版本

如果你的客户授权密钥从不经过你无法控制的服务器，就没有密钥托管、没有单点故障，客户也无需担心你的服务消失后会发生什么。

授权码到底是什么

授权码是一个加密签名的声明：这台机器被允许在某个日期之前运行这个软件。让它不可伪造的是签名私钥。如果私钥留在你的机器上、只有公钥随应用分发，那么验证授权完全不需要网络——客户电脑在本地校验签名即可。

这正是离线授权的全部基础：签名者是你，且只有你。没有任何中间人需要替你持有、转发或"验证"你的密钥。

在线授权服务器的隐性代价

授权即服务（license-as-a-service）平台很方便——它们替你处理签发、验证、试用和吊销。但对小型独立开发者来说，便利的代价很容易被低估：

• 数据暴露面。你发给服务器的每个密钥都成为该平台数据面的一部分。平台被入侵或内部人员滥用并非假设——这是你无法控制的攻击面。
• 单点故障。服务宕机、限流或悄悄关闭时，你的客户将无法验证授权。你的收入依赖第三方的可用性。
• 离线是真实需求。相当大比例的桌面用户会离线工作或身处受限网络（工厂、实验室、政企内网、隔离环境）。如果授权在离线时失效，你恰恰在劝退最需要桌面应用的客户。
• 信任成本。客户必须相信平台不会记录每一次激活（含机器码与销售数据）。

离线签名实际怎么工作

设计简单且久经考验：

1. 生成 RSA（或 Ed25519）密钥对。私钥留在你的机器上——最好放在操作系统保护的凭据库（DPAPI / Keychain / safeStorage），绝不内嵌进应用、绝不上传。
2. 用私钥签发一个紧凑的 JWT 风格令牌：机器码、授权类型、签发/到期时间戳、版本区间、档位。
3. 应用内只内置公钥。激活时本地验签，并校验机器码匹配。
4. 试用、续期、换机与吊销全部通过新的签名令牌完成——全程离线。

因为私钥从不离开你的机器，任何第三方的数据泄露都无法伪造你的授权。服务器端根本没有可偷的东西。

最小签名示例（Node.js，只在你机器上运行）：

// 签发授权令牌——私钥从不离开这台机器
const jwt = require('jsonwebtoken');
const token = jwt.sign(
  { machine: 'ABC1-DEF2-3456-7890', edition: 'pro', type: 12, exp: 1798761600 },
  privateKey,            // 系统凭据库保护，不内嵌进应用
  { algorithm: 'RS256' }
);
// 只分发公钥；本地 jwt.verify(...) 验签

离线诚实地说，你付出了什么

我把 LicenseDesktop 做成离线优先的授权系统，我想坦诚地说清权衡：

• 没有云端的即时吊销。被吊销的授权要等到客户下次签到/续期尝试时才停止工作。如果你需要军规级的"一键封杀"，你需要一个回连通道——离线单靠自己做不了。
• 没有托管的激活统计。你得到的是本地数据库里的激活记录，而不是 SaaS 仪表盘。这是隐私特性，但也意味着报表由你自己维护。
• 在线购买是独立的可选层。支付仍然需要互联网。在我的方案里，购买流程与授权履约可以联网，而签名核心保持本地——店铺与密钥库解耦。

什么时候服务器才是正确答案

如果你的产品是订阅 SaaS、确实需要设备数实时管控与即时锁定，或客户期待 SSO——那么托管授权层是务实选择。离线优先不是教条，而是适配决策。但对于面向开发者、隐私敏感用户或重视数据自主的 B2B 买家的桌面软件，"你的密钥永不离开你的机器"是一个在销售沟通中真正站得住脚的定位优势。

在实践中的样子

在 LicenseDesktop 中，私钥只由主进程读取并存在系统保护的凭据库中；渲染进程永远看不到它。激活码是 RSA 签名的 JWT，用公钥验证、绑定机器码，并用时间高水位（文件 + 注册表双存储）抵御时钟回拨。签发、续期、换机、吊销，甚至 14 天试用——在干净无网的 Windows 机器上全部可用。在线购买、更新与加密云备份是叠加在离线核心之上的可选功能。

如果你想试试离线优先的工作流：下载免费 14 天试用版，大约十分钟签出第一张授权码，看看上面的权衡是否适合你的产品。如果更想先问个问题，联系我——每条消息我都会读。

相关阅读

• 离线授权 vs 在线授权：独立开发者怎么选 （系列预告）
• 授权码验证的原理：RSA 签名 （系列预告）
• 离线授权中的时钟回拨防护 （系列预告）