Web 推送协议

我们已经了解了如何使用库来触发推送消息，但这些库究竟在做什么？

它们会发出网络请求，同时确保这些请求的格式正确。定义此网络请求的规范是 Web 推送协议。

本部分概述了服务器如何使用应用服务器密钥标识自身，以及如何发送加密的载荷和关联数据。

这并不是 Web 推送的漂亮一面，我也不是加密方面的专家，但我们不妨仔细看看每个部分，因为了解这些库在底层执行的操作非常有用。

应用服务器密钥

当我们为用户订阅时，会传入 applicationServerKey。此密钥会传递给推送服务，用于检查订阅用户的应用是否也是触发推送消息的应用。

当我们触发推送消息时，会发送一组标头，以便推送服务对应用进行身份验证。（这由 VAPID 规范定义。）

这一切实际上意味着什么，又会发生什么？以下是应用服务器身份验证所采取的步骤：

1. 应用服务器使用其私有应用密钥对一些 JSON 信息进行签名。
2. 此签名信息会作为 POST 请求中的标头发送到推送服务。
3. 推送服务使用从 pushManager.subscribe() 收到的已存储公钥来检查收到的信息是否由与该公钥相关的私钥签名。请注意：公钥是传递到订阅调用的 applicationServerKey。
4. 如果签名信息有效，推送服务会将推送消息发送给用户。

下面是此信息流的示例。（请注意左下角的图例，其中显示了公钥和私钥。）

添加到请求标头中的“签名信息”是一个 JSON Web 令牌。

JSON Web 令牌

JSON Web 令牌（简称 JWT）是一种向第三方发送消息的方式，接收方可以验证消息的发送者。

当第三方收到消息时，需要获取发送者的公钥并使用该公钥验证 JWT 的签名。如果签名有效，则 JWT 必须已使用匹配的私钥签名，因此必须来自预期的发送者。

jwt.io/ 上有许多库可以为您执行签名，建议您尽可能使用这些库。为了完整起见，我们来看看如何手动创建已签名的 JWT。

Web 推送和已签名的 JWT

已签名的 JWT 只是一个字符串，不过可以将其视为由英文句点连接的三个字符串。

第一个和第二个字符串（JWT 信息和 JWT 数据）是经过 base64 编码的 JSON 片段，这意味着它们是可公开读取的。

第一个字符串是有关 JWT 本身的信息，用于指明创建签名时所用的算法。

Web 推送的 JWT 信息必须包含以下信息：

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

第二个字符串是 JWT 数据。此声明提供有关 JWT 发送者、预期接收者和有效期的信息。

对于 Web 推送，数据将采用以下格式：

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

aud 值是“目标对象”，即 JWT 的适用对象。对于 Web 推送，受众群体是推送服务，因此我们将其设置为推送服务的源。

exp 值是 JWT 的过期时间，这可防止窥探者在拦截 JWT 后重新使用它。过期时间是时间戳（以秒为单位），不得超过 24 小时。

在 Node.js 中，可以使用以下方法设置过期时间：

Math.floor(Date.now() / 1000) + 12 * 60 * 60;

这是 12 小时，而不是 24 小时，以避免发送应用与推送服务之间的时钟差异导致任何问题。

最后，sub 值必须是网址或 mailto 电子邮件地址。 这样一来，如果推送服务需要联系发件人，就可以从 JWT 中找到联系信息。（这就是 web-push 库需要电子邮件地址的原因）。

与 JWT 信息一样，JWT 数据也编码为网址安全的 base64 字符串。

第三个字符串（即签名）是将前两个字符串（JWT 信息和 JWT 数据）用英文句点连接起来（我们称之为“未签名令牌”）并对其进行签名后得到的结果。

签名流程需要使用 ES256 对“未签名的令牌”进行加密。根据 JWT 规范，ES256 是“使用 P-256 曲线和 SHA-256 哈希算法的 ECDSA”的简称。使用 Web Crypto，您可以按如下方式创建签名：

// Utility function for UTF-8 encoding a string to an ArrayBuffer.
const utf8Encoder = new TextEncoder('utf-8');

// The unsigned token is the concatenation of the URL-safe base64 encoded
// header and body.
const unsignedToken = .....;

// Sign the |unsignedToken| using ES256 (SHA-256 over ECDSA).
const key = {
  kty: 'EC',
  crv: 'P-256',
  x: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(1, 33)),
  y: window.uint8ArrayToBase64Url(
    applicationServerKeys.publicKey.subarray(33, 65)),
  d: window.uint8ArrayToBase64Url(applicationServerKeys.privateKey),
};

// Sign the |unsignedToken| with the server's private key to generate
// the signature.
return crypto.subtle.importKey('jwk', key, {
  name: 'ECDSA', namedCurve: 'P-256',
}, true, ['sign'])
.then((key) => {
  return crypto.subtle.sign({
    name: 'ECDSA',
    hash: {
      name: 'SHA-256',
    },
  }, key, utf8Encoder.encode(unsignedToken));
})
.then((signature) => {
  console.log('Signature: ', signature);
});

推送服务可以使用公共应用服务器密钥验证 JWT，以解密签名并确保解密后的字符串与“未签名的令牌”（即 JWT 中的前两个字符串）相同。

签名的 JWT（即由英文句点连接的所有三个字符串）会作为 Authorization 标头发送到 Web 推送服务，并预先添加 WebPush，如下所示：

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

Web 推送协议还规定，公共应用服务器密钥必须在 Crypto-Key 标头中发送，并且必须是网址安全型 base64 编码的字符串，并以 p256ecdsa= 作为前缀。

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

载荷加密

接下来，我们来看看如何通过推送消息发送载荷，以便我们的 Web 应用在收到推送消息时能够访问其收到的数据。

使用过其他推送服务的用户经常会问一个问题：为什么 Web 推送载荷需要加密？对于原生应用，推送消息可以纯文本形式发送数据。

Web 推送的魅力在于，由于所有推送服务都使用相同的 API（Web 推送协议），因此开发者无需关心推送服务提供商是谁。我们可以采用正确的格式发出请求，并期待推送消息能够发送成功。但这样做的缺点是，开发者可能会向不可信的推送服务发送消息。通过加密载荷，推送服务无法读取发送的数据。 只有浏览器可以解密这些信息。这有助于保护用户的数据。

载荷的加密在消息加密规范中定义。

在介绍加密推送消息载荷的具体步骤之前，我们应先了解加密过程中会用到的一些技术。（非常感谢 Mat Scales 撰写了有关推送加密的出色文章。）

ECDH 和 HKDF

ECDH 和 HKDF 都用于整个加密过程，并可为加密信息提供诸多优势。

ECDH：椭圆曲线 Diffie-Hellman 密钥交换

假设有两个人（Alice 和 Bob）想要分享信息。 Alice 和 Bob 各有自己的公钥和私钥。Alice 和 Bob 互相分享各自的公钥。

使用 ECDH 生成的密钥的有用属性是，Alice 可以使用自己的私钥和 Bob 的公钥来创建密钥值“X”。Bob 也可以这样做，他使用自己的私钥和 Alice 的公钥独立创建相同的值“X”。这样一来，X 就成了共享密钥令牌，而 Alice 和 Bob 只需共享各自的公钥。现在，Bob 和 Alice 可以使用“X”来加密和解密彼此之间的消息。

据我所知，ECDH 定义了曲线的属性，这些属性可实现生成共享密钥令牌“X”的“功能”。

以上是对 ECDH 的简要说明；如果您想了解更多信息，建议观看更详细的 ECDH 概览视频。

就代码而言，大多数语言 / 平台都附带了可轻松生成这些密钥的库。

在节点中，我们会执行以下操作：

const keyCurve = crypto.createECDH('prime256v1');
keyCurve.generateKeys();

const publicKey = keyCurve.getPublicKey();
const privateKey = keyCurve.getPrivateKey();

HKDF：基于 HMAC 的密钥派生函数

维基百科对 HKDF 有一个简洁的描述：

HKDF 是一种基于 HMAC 的密钥派生函数，可将任何弱密钥材料转换为加密强度高的密钥材料。例如，它可用于将 Diffie Hellman 交换的共享密钥转换为适合用于加密、完整性检查或身份验证的密钥材料。

从本质上讲，HKDF 会获取不太安全的输入，并使其更安全。

定义此加密的规范要求使用 SHA-256 作为哈希算法，并且 Web 推送中 HKDF 的生成的密钥不应超过 256 位（32 字节）。

在节点中，可以按如下方式实现：

// Simplified HKDF, returning keys up to 32 bytes long
function hkdf(salt, ikm, info, length) {
  // Extract
  const keyHmac = crypto.createHmac('sha256', salt);
  keyHmac.update(ikm);
  const key = keyHmac.digest();

  // Expand
  const infoHmac = crypto.createHmac('sha256', key);
  infoHmac.update(info);

  // A one byte long buffer containing only 0x01
  const ONE_BUFFER = new Buffer(1).fill(1);
  infoHmac.update(ONE_BUFFER);

  return infoHmac.digest().slice(0, length);
}

此示例代码借鉴了 Mat Scale 的文章。

这大致涵盖了 ECDH 和 HKDF。

ECDH 是一种安全地共享公钥和生成共享密钥令牌的方法。HKDF 是一种将不安全材料转化为安全材料的方法。

这将在加密载荷期间使用。接下来，我们来看看输入内容以及加密方式。

输入

如果我们想向用户发送包含载荷的推送消息，需要提供以下三项输入内容：

1. 载荷本身。
2. 来自 PushSubscription 的 auth Secret。
3. PushSubscription 中的 p256dh 键。

我们已经看到从 PushSubscription 中检索到的 auth 和 p256dh 值，但为了快速提醒，假设我们有一个订阅，则需要以下值：

subscription.toJSON().keys.auth;
subscription.toJSON().keys.p256dh;

subscription.getKey('auth');
subscription.getKey('p256dh');

auth 值应视为密钥，不得在应用外部共享。

p256dh 密钥是公钥，有时称为客户端公钥。在本文中，我们将 p256dh 称为订阅公钥。订阅公钥由浏览器生成。浏览器将对私钥保密，并使用该私钥解密载荷。

这三个值（auth、p256dh 和 payload）需要作为输入，加密过程的结果将是加密的载荷、一个盐值和一个仅用于加密数据的公钥。

Salt

盐需要是 16 字节的随机数据。在 NodeJS 中，我们会执行以下操作来创建 salt：

const salt = crypto.randomBytes(16);

公钥 / 私钥

公钥和私钥应使用 P-256 椭圆曲线生成，在 Node 中，我们可以按如下方式生成：

const localKeysCurve = crypto.createECDH('prime256v1');
localKeysCurve.generateKeys();

const localPublicKey = localKeysCurve.getPublicKey();
const localPrivateKey = localKeysCurve.getPrivateKey();

我们将这些密钥称为“本地密钥”。它们仅用于加密，与应用服务器密钥无关。

以载荷、身份验证密钥和订阅公钥作为输入，并使用新生成的盐和一组本地密钥，我们就可以实际执行一些加密操作了。

共享密钥

第一步是使用订阅公钥和我们的新私钥创建共享密钥令牌（还记得 Alice 和 Bob 的 ECDH 说明吗？就是这么简单）。

const sharedSecret = localKeysCurve.computeSecret(
  subscription.keys.p256dh,
  'base64',
);

此值将在下一步中用于计算伪随机密钥 (PRK)。

伪随机标识名

伪随机密钥 (PRK) 是推送订阅的身份验证密钥与我们刚刚创建的共享密钥令牌的组合。

const authEncBuff = new Buffer('Content-Encoding: auth\0', 'utf8');
const prk = hkdf(subscription.keys.auth, sharedSecret, authEncBuff, 32);

您可能想知道 Content-Encoding: auth\0 字符串的用途。 简而言之，它没有明确的用途，尽管浏览器可以解密收到的消息并查找预期的内容编码。\0 会在缓冲区的末尾添加一个值为 0 的字节。这是浏览器解密消息时所期望的，浏览器会期望内容编码有这么多字节，后面跟着一个值为 0 的字节，然后是加密的数据。

我们的伪随机密钥只是通过 HKDF 运行身份验证、共享密钥令牌和一段编码信息（即，使其在加密方面更强大）。

上下文

“上下文”是一组字节，用于稍后在加密浏览器中计算两个值。它本质上是一个字节数组，包含订阅公钥和本地公钥。

const keyLabel = new Buffer('P-256\0', 'utf8');

// Convert subscription public key into a buffer.
const subscriptionPubKey = new Buffer(subscription.keys.p256dh, 'base64');

const subscriptionPubKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = subscriptionPubKey.length;

const localPublicKeyLength = new Uint8Array(2);
subscriptionPubKeyLength[0] = 0;
subscriptionPubKeyLength[1] = localPublicKey.length;

const contextBuffer = Buffer.concat([
  keyLabel,
  subscriptionPubKeyLength.buffer,
  subscriptionPubKey,
  localPublicKeyLength.buffer,
  localPublicKey,
]);

最终的上下文缓冲区是一个标签、订阅公钥中的字节数（后跟密钥本身）、本地公钥中的字节数（后跟密钥本身）。

有了此上下文值，我们就可以在创建随机数和内容加密密钥 (CEK) 时使用它。

内容加密密钥和随机数

nonce 是一种可防止重放攻击的值，因为它只能使用一次。

内容加密密钥 (CEK) 是最终用于加密载荷的密钥。

首先，我们需要为随机数和 CEK 创建数据字节，这只是一个内容编码字符串，后跟我们刚刚计算的上下文缓冲区：

const nonceEncBuffer = new Buffer('Content-Encoding: nonce\0', 'utf8');
const nonceInfo = Buffer.concat([nonceEncBuffer, contextBuffer]);

const cekEncBuffer = new Buffer('Content-Encoding: aesgcm\0');
const cekInfo = Buffer.concat([cekEncBuffer, contextBuffer]);

此信息通过 HKDF 运行，将 salt 和 PRK 与 nonceInfo 和 cekInfo 相结合：

// The nonce should be 12 bytes long
const nonce = hkdf(salt, prk, nonceInfo, 12);

// The CEK should be 16 bytes long
const contentEncryptionKey = hkdf(salt, prk, cekInfo, 16);

这样我们就获得了 Nonce 和内容加密密钥。

执行加密

现在我们有了内容加密密钥，就可以加密载荷了。

我们使用内容加密密钥作为密钥创建 AES128 密码，并将 Nonce 作为初始化向量。

在 Node 中，此操作的实现方式如下：

const cipher = crypto.createCipheriv(
  'id-aes128-GCM',
  contentEncryptionKey,
  nonce,
);

在加密载荷之前，我们需要定义希望在载荷前面添加多少填充。我们之所以要添加填充，是因为这样可以防止窃听者根据载荷大小确定消息的“类型”。

您必须添加两个字节的填充，以指明任何额外填充的长度。

例如，如果您未添加任何填充，则在两个值为 0 的字节（即不存在填充）之后，您将读取载荷。如果您添加了 5 字节的填充，前两个字节的值将为 5，因此使用方随后会再读取 5 个字节，然后开始读取载荷。

const padding = new Buffer(2 + paddingLength);
// The buffer must be only zeros, except the length
padding.fill(0);
padding.writeUInt16BE(paddingLength, 0);

然后，我们通过此密码运行填充和载荷。

const result = cipher.update(Buffer.concat(padding, payload));
cipher.final();

// Append the auth tag to the result -
// https://nodejs.org/api/crypto.html#crypto_cipher_getauthtag
const encryptedPayload = Buffer.concat([result, cipher.getAuthTag()]);

现在，我们有了加密的载荷。耶！

剩下的就是确定如何将此载荷发送到推送服务。

加密的载荷标头和正文

为了将此加密的载荷发送到推送服务，我们需要在 POST 请求中定义几个不同的标头。

加密标头

“Encryption”标头必须包含用于加密载荷的 salt。

16 字节的 salt 应采用 base64 网址 安全编码，并添加到 Encryption 标头中，如下所示：

Encryption: salt=[URL Safe Base64 Encoded Salt]

Crypto-Key 标头

我们看到，Crypto-Key 标头用于“应用服务器密钥”部分，其中包含公共应用服务器密钥。

此标头还用于共享用于加密载荷的本地公钥。

生成的标头如下所示：

Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]

内容类型、长度和编码标头

Content-Length 标头是加密载荷中的字节数。“Content-Type”和“Content-Encoding”标头是固定值。 如下所示。

Content-Length: [Number of Bytes in Encrypted Payload]
Content-Type: 'application/octet-stream'
Content-Encoding: 'aesgcm'

设置这些标头后，我们需要将加密的载荷作为请求的正文发送。请注意，Content-Type 设置为 application/octet-stream。这是因为加密后的载荷必须以字节流的形式发送。

在 NodeJS 中，我们会像这样操作：

const pushRequest = https.request(httpsOptions, function(pushResponse) {
pushRequest.write(encryptedPayload);
pushRequest.end();

更多标头？

我们已介绍用于 JWT / 应用服务器密钥的标头（即如何使用推送服务标识应用），还介绍了用于发送加密载荷的标头。

推送服务还会使用其他标头来改变已发送消息的行为。其中一些标头是必需的，而另一些是可选的。

TTL 标题

必需

TTL（或存留时间）是一个整数，用于指定推送消息在推送服务中存留的时间（以秒为单位），之后才会传送。当 TTL 过期时，相应消息将从推送服务队列中移除，并且不会被传送。

TTL: [Time to live in seconds]

如果您将 TTL 设置为零，推送服务会尝试立即传送消息，但如果无法联系到设备，您的消息会立即从推送服务队列中丢弃。

从技术上讲，推送服务可以根据需要减少推送消息的 TTL。您可以通过检查推送服务响应中的 TTL 标头来判断是否发生了这种情况。

主题

可选

主题是字符串，如果待处理消息的主题名称与新消息的主题名称匹配，则可以使用新消息替换待处理消息。

在设备处于离线状态时发送多条消息，但您只希望用户在设备开启时看到最新消息，这种情况下此功能非常有用。

紧急情况

可选

紧急程度用于向推送服务表明消息对用户的重要性。推送服务可以使用此功能，在电池电量不足时仅唤醒设备以接收重要消息，从而帮助用户节省设备电量。

标头值的定义如下所示。默认值为 normal。

Urgency: [very-low | low | normal | high]

所有内容

如果您对上述所有功能的运作方式有其他疑问，可以随时查看库如何在 web-push-libs 组织上触发推送消息。

获得加密载荷和上述标头后，您只需在 PushSubscription 中向 endpoint 发出 POST 请求。

那么，我们应该如何处理此 POST 请求的响应呢？

来自推送服务的响应

向推送服务发出请求后，您需要检查响应的状态代码，以了解请求是否成功。

您还可以阅读 Web 推送标准 (RFC8030)，详细了解 HTTP 状态代码。

下一步做什么

• 网页推送通知概览
• 推送的运作方式
• 订阅用户
• 权限用户体验
• 使用 Web 推送库发送消息
• Web 推送协议
• 处理推送事件
• 显示通知
• 通知行为
• 常见通知模式
• 推送通知常见问题解答
• 常见问题和报告 bug

Codelab

• 构建推送通知客户端
• 构建推送通知服务器