Noções básicas de Web Push: inscrições, chaves VAPID e o serviço de push

O que é

A RFC 8030 define três partes: o navegador cria uma inscrição em um serviço de push escolhido pelo seu fabricante e recebe uma URL de endpoint; a página envia essa inscrição, incluindo as respectivas chaves de criptografia, ao servidor da aplicação; mais tarde, o servidor envia uma mensagem por POST para o endpoint, e o serviço de push a entrega ao navegador, que aciona o evento push de um service worker. Toda requisição de entrega precisa incluir o cabeçalho TTL (segundos durante os quais o serviço pode reter a mensagem) e pode incluir Urgency e Topic (uma nova mensagem substitui uma mensagem ainda não entregue com o mesmo tópico). O VAPID (RFC 8292) identifica o servidor da aplicação: trata-se de um JWT assinado com uma chave ES256 (ECDSA em P-256), cuja claim aud é a origem do endpoint de push, com exp de no máximo 24 horas no futuro e uma URI de contato sub opcional, enviado como Authorization: vapid t=<jwt>, k=<public key>. A mesma chave pública é passada a PushManager.subscribe() como applicationServerKey; a MDN enfatiza que essa não é a chave usada para criptografar os payloads e que o Chrome e o Edge rejeitam inscrições, a menos que userVisibleOnly seja true. Os payloads são criptografados de ponta a ponta (Content-Encoding: aes128gcm), por isso o serviço de push não consegue lê-los.

Por que importa

O push alcança os usuários mesmo com o site fechado, mas a permissão, o tratamento das chaves, a criptografia e a expiração da inscrição podem, cada um, falhar silenciosamente: não há erro na página, apenas mensagens que nunca chegam.

Como aplicar

• Gere um par de chaves VAPID por aplicação e guarde a chave privada em um sistema de gerenciamento de segredos; as inscrições ficam vinculadas à chave pública, portanto rotacioná-la significa inscrever novamente todos os usuários.
• Solicite a permissão de notificações em resposta a uma ação do usuário e com uma finalidade explicada; uma solicitação não provocada ao carregar a página costuma ser negada, e uma negação é difícil de reverter.
• Armazene as inscrições no servidor, associadas ao usuário; quando o serviço de push responder 404, que a RFC 8030 especifica para uma inscrição expirada, exclua o registro.
• Use uma biblioteca mantida para a criptografia e para o JWT; uma implementação incorreta de aes128gcm gera requisições que o serviço de push aceita, mas que o navegador não consegue descriptografar.
• Defina o TTL de acordo com o período em que a mensagem continua útil e mantenha os payloads pequenos: os serviços não são obrigados a aceitar corpos acima de 4096 bytes.
• Trate o evento pushsubscriptionchange no service worker para se inscrever novamente e reenviar a nova inscrição.

Armadilhas

Confundir a chave VAPID com as chaves de criptografia do payload. Receber um push e não exibir nenhuma notificação, o que contradiz a promessa userVisibleOnly feita no momento da inscrição. Interpretar um 201 do serviço de push como entrega. Tratar a URL do endpoint como pública: sem applicationServerKey, qualquer pessoa que a tenha pode enviar mensagens a esse navegador; com ela, a RFC 8292 exige que o serviço de push rejeite requisições sem um token assinado pela chave privada correspondente, por isso proteja ambas.