Fundamentos de Web Push: suscripciones, claves VAPID y el servicio push

Qué es

RFC 8030 define tres partes: el navegador crea una suscripción con un servicio push elegido por su proveedor y recibe una URL de endpoint; la página envía esa suscripción, incluidas sus claves de cifrado, al servidor de la aplicación; el servidor envía más tarde un mensaje mediante POST al endpoint, y el servicio push lo entrega al navegador, que activa el evento push de un service worker. Toda solicitud de entrega debe llevar un encabezado TTL (segundos que el servicio puede retener el mensaje) y puede llevar Urgency y Topic (un mensaje nuevo reemplaza a uno no entregado con el mismo topic). VAPID (RFC 8292) identifica al servidor de la aplicación: un JWT firmado con una clave ES256 (ECDSA sobre P-256) cuya afirmación aud es el origen del endpoint push, exp con un máximo de 24 horas de anticipación y un URI de contacto sub opcional, enviado como Authorization: vapid t=<jwt>, k=<public key>. La misma clave pública se pasa a PushManager.subscribe() como applicationServerKey; MDN recalca que esta no es la clave usada para cifrar las cargas útiles, y que Chrome y Edge rechazan las suscripciones a menos que userVisibleOnly sea true. Las cargas útiles se cifran de extremo a extremo (Content-Encoding: aes128gcm), de modo que el servicio push no puede leerlas.

Por qué importa

Push llega a los usuarios mientras el sitio está cerrado, pero el permiso, el manejo de claves, el cifrado y la expiración de la suscripción pueden fallar cada uno en silencio: sin error en la página, solo mensajes que nunca llegan.

Cómo aplicarlo

• Generar un par de claves VAPID por aplicación y mantener la clave privada en un gestor de secretos; las suscripciones quedan ligadas a la clave pública, de modo que rotarla implica volver a suscribir a cada usuario.
• Solicitar el permiso de notificaciones en respuesta a una acción del usuario con un propósito declarado; una solicitud no motivada al cargar la página suele denegarse, y una denegación es difícil de revertir.
• Almacenar las suscripciones en el servidor junto con el usuario; cuando el servicio push responde 404, que es lo que RFC 8030 especifica para una suscripción expirada, eliminar el registro.
• Usar una biblioteca mantenida para el cifrado y el JWT; una implementación incorrecta de aes128gcm produce solicitudes que el servicio push acepta pero que el navegador no puede descifrar.
• Fijar TTL según la ventana de utilidad del mensaje y mantener las cargas útiles pequeñas: los servicios no están obligados a aceptar cuerpos de más de 4096 bytes.
• Gestionar el evento pushsubscriptionchange en el service worker para volver a suscribirse y subir la nueva suscripción.

Trampas

Confundir la clave VAPID con las claves de cifrado de la carga útil. Recibir un push y no mostrar ninguna notificación, lo que contradice la promesa de userVisibleOnly hecha al suscribirse. Interpretar un 201 del servicio push como entrega. Tratar la URL del endpoint como pública: sin applicationServerKey, cualquiera que la posea puede enviar solicitudes a ese navegador; con ella, RFC 8292 exige que el servicio push rechace las solicitudes que no lleven un token firmado con la clave privada correspondiente, así que hay que proteger ambas cosas.