VAPID, Voluntary Application Server Identification for Web Push, is RFC 8292. Your server signs a short-lived token with its own private key and sends it with each push request, so the push service can tell who is sending and a subscription can be limited to your key.
Definition
When your server asks a push service to deliver a message, VAPID lets it voluntarily identify itself. The server signs a JSON Web Token and sends it in an Authorization header using the vapid scheme. The token goes in the t parameter and the matching public key in the k parameter. By signing, the server shows it holds the private key for the public key it sends.
The signature uses ECDSA on the P-256 curve with ES256. The RFC also says the signing key must differ from the key used for message encryption.
The token claims
| Claim | Required | Notes from the RFC |
|---|---|---|
| aud | Yes | Origin of the push resource URL. The token is reusable for all push URLs on that origin |
| exp | Yes | Must not be more than 24 hours from the time of the request |
| sub | Optional | A contact URI such as mailto or https, so the push operator can reach you. It is unvalidated and should not drive security decisions |
Keep extra claims small, because the token travels in a header.
Why it matters
The RFC describes two benefits. First, identity helps push services separate legitimate traffic from bogus traffic, which supports denial of service resilience. Second, a browser can restrict a subscription to a public key, so only the server with the matching private key can use it. That reduces dependence on keeping the subscription URL secret, though you should still protect the URL. See are push subscription URLs secret.
The design is voluntary on purpose, to preserve privacy for senders who prefer not to identify themselves.
Risks and hygiene
A stolen token can be replayed until it expires. The RFC mitigates this with HTTPS and short lifetimes, so keep exp short in practice. Reusing a token for its lifetime lets push services cache validation results.
Changing the signing key breaks linkability with earlier traffic, and push services may treat requests from a new key with suspicion, so the RFC recommends gradual migration.
Steps
- Generate a dedicated P-256 key pair for VAPID. Do not reuse an encryption key.
- Keep the private key in your secrets manager with access limited to the sending service.
- Set a contact in sub that reaches a monitored mailbox.
- Set exp well inside 24 hours and refresh tokens before they lapse.
- Subscribe browsers with your public key so subscriptions bind to it.
- Plan a rotation: add a new key, migrate in stages, then retire the old one.
Where Safeguard fits
Safeguard's agent identity and policy features help teams control which services hold signing keys, and its dependency scanning covers the push libraries you use. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is VAPID encryption?
No. It identifies the sender. Message content is protected by the separate encryption in RFC 8291.
Can the token live for a week?
No. The RFC says exp must not be more than 24 hours from the time of the request.
Sources
Last reviewed: 19 October 2026.
