Web-Push-Grundlagen: Subscriptions, VAPID-Schlüssel und der Push-Dienst

Worum es geht

RFC 8030 definiert drei Parteien: Der Browser erstellt ein Abonnement bei einem von seinem Hersteller gewählten Push-Dienst und erhält eine Endpoint-URL; die Seite sendet dieses Abonnement, samt seiner Verschlüsselungsschlüssel, an den Anwendungsserver; der Server sendet später eine Nachricht per POST an den Endpoint, und der Push-Dienst stellt sie dem Browser zu, der das push-Ereignis eines Service Workers weckt. Jede Zustellanfrage muss einen TTL-Header tragen (Sekunden, die der Dienst die Nachricht vorhalten darf) und kann Urgency und Topic tragen (eine neue Nachricht ersetzt eine nicht zugestellte mit demselben Thema). VAPID (RFC 8292) identifiziert den Anwendungsserver: ein mit einem ES256-Schlüssel (ECDSA auf P-256) signiertes JWT, dessen aud-Claim der Ursprung des Push-Endpoints ist, exp höchstens 24 Stunden in der Zukunft und ein optionaler sub-Kontakt-URI, gesendet als Authorization: vapid t=<jwt>, k=<public key>. Derselbe öffentliche Schlüssel wird PushManager.subscribe() als applicationServerKey übergeben; MDN betont, dass dies nicht der Schlüssel ist, mit dem Payloads verschlüsselt werden, und dass Chrome und Edge Abonnements ablehnen, sofern userVisibleOnly nicht true ist. Payloads sind Ende-zu-Ende verschlüsselt (Content-Encoding: aes128gcm), sodass der Push-Dienst sie nicht lesen kann.

Warum es wichtig ist

Push erreicht Nutzer, während die Site geschlossen ist, aber Berechtigung, Schlüsselverwaltung, Verschlüsselung und Ablauf des Abonnements können jeweils stillschweigend fehlschlagen: kein Fehler auf der Seite, nur Nachrichten, die nie ankommen.

So wird es angewendet

• Pro Anwendung ein VAPID-Schlüsselpaar erzeugen und den privaten Schlüssel im Secrets-Management aufbewahren; Abonnements sind an den öffentlichen Schlüssel gebunden, sein Rotieren bedeutet also, jeden Nutzer neu abonnieren zu lassen.
• Die Benachrichtigungsberechtigung als Reaktion auf eine Nutzeraktion mit erklärtem Zweck anfragen; eine ungefragte Anfrage beim Laden der Seite wird häufig abgelehnt, und eine Ablehnung ist schwer rückgängig zu machen.
• Abonnements serverseitig beim Nutzer speichern; antwortet der Push-Dienst mit 404, was RFC 8030 für ein abgelaufenes Abonnement vorgibt, den Datensatz löschen.
• Für Verschlüsselung und JWT eine gepflegte Bibliothek verwenden; eine fehlerhafte aes128gcm-Implementierung erzeugt Anfragen, die der Push-Dienst annimmt, der Browser aber nicht entschlüsseln kann.
• TTL nach dem Nutzenfenster der Nachricht setzen und Payloads klein halten: Dienste müssen Bodies über 4096 Byte nicht akzeptieren.
• Das pushsubscriptionchange-Ereignis im Service Worker behandeln, um erneut zu abonnieren und das neue Abonnement hochzuladen.

Stolpersteine

Den VAPID-Schlüssel mit den Payload-Verschlüsselungsschlüsseln verwechseln. Eine Push erhalten und keine Benachrichtigung anzeigen, was dem bei der Anmeldung gegebenen userVisibleOnly-Versprechen widerspricht. Einen 201 vom Push-Dienst als Zustellung lesen. Die Endpoint-URL als öffentlich behandeln: Ohne applicationServerKey kann jeder, der sie besitzt, an diesen Browser posten; mit ihm verlangt RFC 8292, dass der Push-Dienst Anfragen ohne ein vom passenden privaten Schlüssel signiertes Token ablehnt – also beide schützen.