Les bases de Web Push : abonnements, clés VAPID et le service de push

Ce que c'est

La RFC 8030 définit trois parties : le navigateur crée un abonnement auprès d'un service de push choisi par son éditeur et reçoit une URL de point de terminaison ; la page envoie cet abonnement, y compris ses clés de chiffrement, au serveur applicatif ; le serveur envoie ensuite par POST un message au point de terminaison, et le service de push le délivre au navigateur, qui réveille l'événement push d'un service worker. Chaque requête de livraison doit porter un en-tête TTL (secondes pendant lesquelles le service peut retenir le message) et peut porter Urgency et Topic (un nouveau message remplace un message non délivré portant le même sujet). VAPID (RFC 8292) identifie le serveur applicatif : un JWT signé avec une clé ES256 (ECDSA sur P-256) dont la revendication aud est l'origine du point de terminaison de push, exp à au plus 24 heures dans le futur et une URI de contact sub facultative, envoyé sous la forme Authorization: vapid t=<jwt>, k=<public key>. La même clé publique est transmise à PushManager.subscribe() comme applicationServerKey ; MDN souligne qu'il ne s'agit pas de la clé utilisée pour chiffrer les charges utiles, et que Chrome et Edge rejettent les abonnements à moins que userVisibleOnly ne soit vrai. Les charges utiles sont chiffrées de bout en bout (Content-Encoding: aes128gcm), si bien que le service de push ne peut pas les lire.

Pourquoi c'est important

Le push atteint les utilisateurs alors que le site est fermé, mais la permission, la gestion des clés, le chiffrement et l'expiration de l'abonnement peuvent chacun échouer silencieusement : aucune erreur sur la page, seulement des messages qui n'arrivent jamais.

Comment l'appliquer

• Générer une paire de clés VAPID par application et garder la clé privée dans une gestion de secrets ; les abonnements sont liés à la clé publique, donc la renouveler implique de réabonner chaque utilisateur.
• Demander la permission de notification en réponse à une action de la personne utilisatrice, avec un but énoncé ; une demande non sollicitée au chargement de la page est couramment refusée, et un refus est difficile à inverser.
• Stocker les abonnements côté serveur avec la personne concernée ; lorsque le service de push répond 404, ce que la RFC 8030 prescrit pour un abonnement expiré, supprimer l'enregistrement.
• Utiliser une bibliothèque maintenue pour le chiffrement et le JWT ; une implémentation incorrecte d'aes128gcm produit des requêtes que le service de push accepte mais que le navigateur ne peut pas déchiffrer.
• Fixer TTL selon la fenêtre d'utilité du message et garder les charges utiles petites : les services ne sont pas tenus d'accepter des corps de plus de 4096 octets.
• Gérer l'événement pushsubscriptionchange dans le service worker pour se réabonner et retéléverser le nouvel abonnement.

Pièges

Confondre la clé VAPID avec les clés de chiffrement de la charge utile. Recevoir un push et n'afficher aucune notification, ce qui contredit la promesse userVisibleOnly faite au moment de l'abonnement. Interpréter un 201 du service de push comme une livraison. Traiter l'URL du point de terminaison comme publique : sans applicationServerKey, quiconque la détient peut envoyer un message par POST à ce navigateur ; avec elle, la RFC 8292 exige que le service de push rejette les requêtes dépourvues d'un jeton signé par la clé privée correspondante — il faut donc protéger les deux.