Blog · Web Push
Claves VAPID explicadas: qué son y por qué deberían ser tuyas
Las claves VAPID identifican a quien envía tus notificaciones push y atan cada suscripción a ese remitente. Qué son, por qué deben ser tuyas y qué reglas seguir.
Las claves VAPID son un par de claves, pública y privada, que identifican a quien envía tus notificaciones push. El navegador usa la pública al crear cada suscripción y, desde ese momento, el servicio push solo acepta avisos para esa suscripción de quien tenga la privada. Por eso quien controla la clave privada controla, en la práctica, tu lista de suscriptores.
En resumen:
- VAPID (RFC 8292) es la forma estándar de que el remitente de un push se identifique ante los servicios push de Google, Mozilla, Apple y Microsoft.
- La clave pública no es secreta: tu web se la entrega al navegador al suscribir. La privada nunca debe salir del sistema que envía.
- Cada suscripción queda atada a un par concreto: si cambias de claves, o pierdes las de un proveedor que no te deja exportarlas, tus usuarios tienen que suscribirse otra vez.
- Tres reglas: guarda la privada como un secreto, no la rotes sin motivo y declara un contacto
mailto:ohttps:.- Antes de elegir proveedor, comprueba que puedes exportar las claves y los suscriptores.
Qué es VAPID y qué problema resuelve
VAPID significa Voluntary Application Server Identification y está definido en el RFC 8292. Resuelve un problema concreto: los servicios push de los navegadores reciben mensajes de remitentes de todo el mundo y necesitan saber quién envía cada uno, poder contactar con él si algo va mal y, sobre todo, impedir que alguien escriba a suscriptores que no son suyos. En lugar de obligarte a darte de alta en cada servicio, VAPID te deja identificarte con un par de claves propio.
Piensa en ellas como un sello. La clave pública es el dibujo del sello, que cualquiera puede ver y comparar; la privada es el sello físico, que solo debe estar en manos de quien envía. Cuando un mensaje llega al servicio push, este comprueba que lleva el sello correcto antes de entregarlo.
Un detalle que evita confusiones: las claves VAPID no son las que protegen el contenido. Cada suscripción trae además sus propias claves de cifrado, creadas por el navegador, para que solo ese dispositivo pueda leer el mensaje. VAPID identifica al remitente y el cifrado protege lo que dice: son piezas distintas con funciones distintas. Si quieres ver dónde encaja cada una en el recorrido de un aviso, lo contamos en qué es Web Push y cómo funciona.
La clave pública ata cada suscripción a quien envía
Cuando un usuario acepta las notificaciones, tu página le pasa al navegador la clave pública VAPID (en la Push API se llama applicationServerKey). El navegador la entrega a su servicio push al crear la suscripción, y el servicio la apunta junto a la dirección de ese navegador. A partir de ahí, esa suscripción solo acepta avisos de quien demuestre tener la clave privada correspondiente.
Esa atadura tiene dos consecuencias prácticas:
- Nadie más puede escribir a tus suscriptores, aunque se filtre la lista de direcciones. Sin la clave privada, el servicio push rechaza los mensajes.
- No puedes cambiar de claves sin perder suscripciones. Las existentes siguen atadas al par antiguo. Para pasar al nuevo, cada usuario tiene que volver a tu web y suscribirse otra vez.
Un ejemplo con números redondos: una web con 20.000 suscriptores que cambia de claves no pierde la lista, pero sí la capacidad de escribirles. Solo recupera a quienes vuelven a visitarla y aceptan de nuevo, y no tiene forma de avisar a los demás de que deben volver, porque el canal para avisarles era justo el push.
Por qué las claves deberían ser tuyas
Si usas un servicio de notificaciones, lo normal es que él cree y guarde tus claves VAPID. Eso no es un problema mientras puedas llevártelas. Sí lo es si el proveedor no te deja exportar la clave privada: tus suscripciones quedan atadas a una clave que no controlas y, el día que quieras cambiar de proveedor, tendrás miles de direcciones válidas a las que no podrás escribir. La única salida sería pedir a cada usuario que se suscriba de nuevo.
Antes de elegir proveedor, haz tres preguntas:
- ¿Puedo exportar la clave privada VAPID, y no solo la pública?
- ¿Puedo exportar cada suscripción completa, con su dirección y sus claves de cifrado, y no solo un identificador interno?
- ¿Las claves son por proyecto, de modo que cada web o producto tiene las suyas?
Si alguna respuesta es «no», la lista de suscriptores es del proveedor, no tuya. La tercera pregunta importa más de lo que parece: si algún día vendes un producto o se lo pasas a otro equipo, querrás entregar sus claves sin entregar las de los demás.
Tres reglas prácticas
Guarda la clave privada como un secreto
Su sitio son las variables secretas de tu plataforma o un gestor de secretos, nunca el repositorio, la configuración del frontend o un mensaje en el chat del equipo. Haz copia de seguridad: perderla equivale a perder la posibilidad de escribir a todos tus suscriptores. Y si se filtra, quien la tenga y conozca sus direcciones podría enviarles mensajes en tu nombre.
No las rotes sin motivo
Con otros secretos, rotar cada cierto tiempo es buena práctica. Con las claves VAPID es al revés: cada rotación obliga a suscribir de nuevo a toda tu audiencia. Créalas una vez por web o producto y no las cambies salvo por una filtración. Vigila los scripts de despliegue que las regeneran al arrancar y los entornos nuevos que crean las suyas: invalidan en silencio todas las suscripciones. Usa además un par distinto para pruebas, porque una suscripción creada en staging no sirve con las claves de producción.
Declara un contacto
VAPID incluye un campo de contacto, el subject, que debe ser una dirección mailto: o una URL https:. El estándar lo deja como opcional, pero Apple rechaza los envíos cuyo contacto no sea una URL o un mailto:, como indica su documentación de Web Push. Sin él no llegarías a Safari ni al iPhone. Usa un buzón que alguien lea, como mailto:push@tudominio.com: es la vía que tiene el operador de un servicio push para avisarte si tus envíos causan problemas.
Cómo lo gestiona castly
En castly cada proyecto (una web o un producto) tiene su propio par VAPID, creado al dar de alta el proyecto y con el contacto ya configurado. La clave privada se guarda cifrada y nunca pasa por tu frontend: el SDK solo usa la pública para suscribir, y para enviar te basta con tu clave de API.
Y como las claves son tuyas, puedes llevártelas cuando quieras. GET /v1/project/export, o el botón Exportar del panel, devuelve el par VAPID con su contacto y todos los suscriptores con sus datos completos:
curl https://castly.sh/v1/project/export \
-H "Authorization: Bearer $CASTLY_SECRET_KEY" \
-o export.json{
"vapid": { "publicKey": "BK-Lyx…", "privateKey": "…", "subject": "mailto:…" },
"subscribers": [
{ "id": "…", "endpoint": "https://…", "keys": { "p256dh": "…", "auth": "…" }, "userId": "user_123" }
]
}Ese archivo es lo que te permite cambiar de proveedor sin que tus usuarios tengan que suscribirse otra vez. Guárdalo con el mismo cuidado que la clave privada, porque la contiene. Tienes el formato completo en la referencia de la API.
Preguntas frecuentes
¿Las claves VAPID son obligatorias?
En la práctica sí. Chrome, Edge y Safari exigen una clave pública para crear la suscripción, y todos los servicios push actuales aceptan VAPID. Es la forma estándar de identificarte sin darte de alta en cada servicio.
¿La clave pública VAPID es secreta?
No. Viaja en el código de tu página y cualquiera puede verla. Lo único que debes proteger es la clave privada.
¿Caducan las claves VAPID?
No. Sirven indefinidamente mientras no las cambies. Lo que sí caduca son las suscripciones individuales, cuando un usuario revoca el permiso o borra los datos del navegador.
¿Qué hago si se filtra la clave privada?
Trátalo como un incidente de seguridad: el par filtrado deja de ser fiable y tendrás que pasar a uno nuevo, lo que implica volver a suscribir a tus usuarios. Por eso merece la pena proteger la privada más que casi cualquier otro secreto.
¿Puedo usar las mismas claves en varias webs?
Técnicamente sí, porque la clave solo identifica al remitente. Pero no conviene: una filtración afectaría a todas las webs a la vez y no podrías traspasar una sin entregar también la clave de las demás.