But it's good to know what they are doing. They make the network requests while ensuring they are in the right format. The spec that defines this network request is Web Push Protocol.

Let's see in detail what these libraries do and how all the components involved in this process maintain the authenticity and integrity of the Push Messages.

Application Server Keys

When we try to subscribe a user for the Push Notifications, we have to pass an applicationServerKey to the subscribe function. The browser forwards this key to the Push service which later uses it to verify that the same application which subscribed the user is triggering the push messages.

The Push Service verifies the authenticity of the push message through some headers that we need to set in our request which are defined by the VAPID spec.

Below I've mentioned the steps of how everything works.

1. We need to sign some JSON information with our private application key on our server.

2. Then we send this signed information as a header in a POST request for Push Message.

3. The Push Service verifies that the Push Message is sent by us using our public key to check the received information is signed by our private key (relating to that public key). The public key is the same applicationServerKey we pass to the subscribe call from our website.

4. The Push Service sends the push message to the user if the signed information is valid.

Here is an example of this flow of information.

JSON web token (Authentication)

JSON web tokens (JWTs) are used to send a message to any third party such that the receiver can validate who sent it. The "signed information" we add to a header in the request is a JSON web token.

The image below shows an example of the JSON web token. It is just a string, though we can think of it as three strings separated by dots. However, the actual JWTs are way longer, this is just for the visualization.

The first and second strings (the JWT info and JWT data) are JSON objects that are base64 encoded. This means that anyone can read them by decoding them.

The first part of the JWT string

The first string is the information about the JWT, it indicates which algorithm was used to create the signature (the third string which we'll discuss later).

The JWT info for web push must contain the following information:

{
  "typ": "JWT",
  "alg": "ES256"
}

The second part of the JWT string

The second string is the JWT Data. This has the information about the sender of the JWT, who it's intended for, and how long it's valid.

For web push, the JWT data would have this format:

{
  "aud": "https://some-push-service.org",
  "exp": "1469618703",
  "sub": "mailto:example@web-push-book.org"
}

The aud value is the "audience", meaning who the JWT is for. For web push requests the audience is the Push Service, so we set it to the origin of the Push Service.

The exp is the expiration of the JWT. The expiration is a timestamp in seconds and we should not keep it longer than 24 hours to prevent snoopers from being able to re-use it if they somehow intercept it.

Finally, the sub value needs to be a URL or a mailto email address so that the push service can contact the sender if it needs to. (This is why the web-push library also requires an email address)

The third part of the JWT string

The third string, the signature, is the result of taking the first two strings (the JWT info and JWT data), joining them with a dot character, which we'll call the "unsigned token", and signing it.

The signature is obtained by encrypting the "unsigned token" using ES256. According to the JWT spec, ES256 is short for "ECDSA using the P-256 curve and the SHA-256 hash algorithm".

A Push Service can decrypt the signature using the public application server key and verify if it's the same as the "unsigned token" (the first two strings in the JWT) to validate the request it receives.

The signed JWT (the three strings concatenated with dots) is included in the Authorization header, prefixed by "WebPush", and sent to the Web Push service, like this:

Authorization: 'WebPush [JWT Info].[JWT Data].[Signature]';

The Web Push Protocol also states that the public application server key should be sent in the Crypto-Key header as a URL-safe base64 encoded string with p256ecdsa prefix.

Crypto-Key: p256ecdsa=[URL Safe Base64 Public Application Server Key]

The Payload Encryption

Now that we've covered authentication, let's dive into payload encryption. You might wonder why we need to encrypt the payload for web push when other push services don't. Well, it's all about maintaining user privacy across different push services.

With web push, developers don't need to worry about which push service they're using. We just follow the protocol, and our message gets sent. But this convenience comes with a catch - we could potentially send messages through an untrustworthy push service. By encrypting the payload, we ensure that only the user's browser can read the data.

The encryption of the payload is defined in the Message Encryption Spec.

In the below breakdown, I have simply provided the steps for encrypting the payload. I'm not going into the details of various techniques used like ECDH (Elliptic Curve Diffie-Hellman key exchange) and HKDF (HMAC-based Key Derivation Function) etc.

So let's break down the encryption process:

1. Inputs: We need three things to start - the payload itself, the auth secret, and the p256dh key that we got from the PushSubscription.

2. Salt and Keys: We generate a random 16-byte salt and create a new set of public/private keys just for this encryption. These are separate from our application server keys.

3. Shared Secret: Using some fancy crypto magic (ECDH, for the curious), we create a shared secret using the subscription's public key and our new private key.

4. Pseudo Random Key (PRK): We combine the auth secret and shared secret to create a PRK. This adds an extra layer of security.

5. Content Encryption Key (CEK) and Nonce: These are derived from the PRK and some additional info. The CEK is what we'll use to actually encrypt our payload.

6. Encryption: Finally, we encrypt our payload using the CEK and nonce. We also add some padding to prevent eavesdroppers from guessing message types based on size.

Once we've got our encrypted payload, we need to package it up with the right headers:

1. Encryption Header: This contains the salt used for encrypting the payload.

    Encryption: salt=[URL Safe Base64 Encoded Salt]
   

2. Crypto-Key Header: This contains our local public key (used for this specific encryption) and our application server public key which we added earlier.

    Crypto-Key: dh=[URL Safe Base64 Encoded Local Public Key String]; p256ecdsa=[URL Safe Base64 Encoded Public Application Server Key]
   

3. Content Headers: These specify the length, type, and encoding of our payload.

    Content-Length: [Number of Bytes in Encrypted Payload]
    Content-Type: 'application/octet-stream'
    Content-Encoding: 'aesgcm'
   

We also have a few optional headers that can control how our push message is handled:

• TTL (Time to Live): This tells the push service how long to keep trying to deliver the message.

    TTL: [Time to live in seconds]
  

  If you set a TTL of zero, the push service will attempt to deliver the message immediately, but if the device can't be reached, your message will be immediately dropped from the push service queue.

• Topic: Useful for replacing older messages with newer ones.

• Urgency: Helps push services manage battery life by prioritizing messages.

    Urgency: [very-low | low | normal | high]
  

With all this setup, we make a POST request to the endpoint specified in the PushSubscription. The push service will then handle delivering our message to the user's device.

Response from Push Service

After sending our push message, we need to check the response from the push service. The status codes tell us if everything went smoothly or if we need to take action:

By following this protocol, we ensure that our push messages are secure, authenticated, and properly handled by push services. It might seem like a lot, but remember - most of this complexity is handled by libraries. As developers, we just need to understand the basics to use these tools effectively.

Conclusion

And there you have it - the Web Push Protocol in a nutshell. It may seem complex, but this intricacy is what makes web push notifications secure and universal across different browsers and devices.

While most of us won't implement this from scratch, understanding the process helps us use push notifications more effectively and troubleshoot issues when they arise. It's a perfect example of how modern web technologies balance user convenience with robust security.

So next time you send a push notification, you'll know exactly what's happening behind the scenes. Happy pushing!

In this article, I will answer some prominent questions on web push notifications.

Web Push Notifications (aka Browser Push Notifications) is a way to send some message to users even when they are not actively using the website. This provides a very convenient way for website owners to increase user engagement on the website.

Web push notifications are shown to the user differently based on what platform, device, and browser the user is using.

Push Messages and Notifications are two separate but complementary browser technologies that work hand in hand to enable Web Push Notifications for websites. Push messages are a way for your server to send messages to the users' browsers. The notifications are what display that message to the user. It's possible to show the notifications without receiving the push message when the user is using your website. However, browsers currently don't support sending just a push message (silent push) to the user. You have to show the notification for the message you are sending to the user.

First, let's learn how Web Push Notifications differ from App Push Notifications. They drive people people crazy when they don't work as per people's expectations.

Difference between Web Push Notifications and App Push Notifications

Apps use their own or any third-party Push Notifications server which maintains the connection with their app on users' devices and can send Push Notifications. The user receives a notification for the apps even when the app is closed.

However, our website doesn't have the power to keep a connection with any server when they are closed. So, it has few limitations as compared to apps. For the websites, the browser companies maintain a Push Service or may use any other third-party push service. The website needs to send the notification that they want to show to users to these Push Services through Web Push Protocol. I will explain the Web Push Protocol in detail in the next article of this series.

How do Web Push Notifications work?

At a high level, the key steps for implementing push notifications are:

1. Adding frontend logic to ask the user for permission to send push notifications and then sending the unique client identifier to the server for storage.

2. Adding backend logic to send push messages to the user through the browser's push service.

3. Adding frontend logic to receive messages and display them as notifications.

I will create a complete code guide for sending push notifications in the upcoming articles. For now, let's understand step-by-step the overview of how push notifications are sent.

Get permission to send push notifications

First, your website needs a user's permission to send push notifications. To get the user notification, you need to call the Notification.requestPermission() function which will prompt the user for permission. However, this function should only be called on some user actions like a button click (which is also called the soft ask method) because most browsers don't allow certain actions without any user interaction and the notifications permission is one of them.

Subscribe the client to push notifications

After getting the permission, your website needs to subscribe the user for the push notifications. This is done through the Push API of browsers. You'll need to provide a public key during the subscription process (more on that later). The browser will then contact the push service for the subscription and return a PushSubscription object. This object data has to be stored by your server to send the push notifications afterward.

Send a push message

Your server doesn't directly send messages to the user. It has to send the message to the push service which is controlled by the users' browser vendor. The request that your server sends to the push service is called a web push protocol request. It should include:

• what is the data to be sent

• to which user the data has to be sent

• Instructions to the push service on how it should deliver the push message. For example, you can specify that the push service should stop attempting to send the message after 10 minutes.

Your server doesn't have to construct the raw web push request itself. Some libraries can handle that for you, such as the web-push-libs.

The push service receives the request, authenticates it, and then sends it to the appropriate client (user). If the client's browser is offline, the push service will queue the message and wait for the browser to come online.

You need to make sure you send the push message request to the correct push service (this is also taken care of by web-push-libs). The PushSubscription data that the browser returned to you during the subscription process provides this information. This is what a PushSubscription object looks like:

{
  "endpoint": "https://fcm.googleapis.com/fcm/send/c1KrmpTuRm…",
  "expirationTime": null,
  "keys": {
    "p256dh": "BGyyVt9FFV…",
    "auth": "R9sidzkcdf…"
  }
}

The domain of the endpoint is essentially the push service, and the endpoint's path is the client identifier using which the push service determines which client to send the message. The keys are used for encryption.

Encrypt the push message

The data that you send to the push service must be encrypted using the keys provided in the PushSubscription. It prevents the push service from reading the data. The browser might be using a third-party push service which can be unsafe or insecure. So it's best to encrypt your messages.

Sign your web push protocol requests

So, now what prevents others who get to know your users' PushSubscription's endpoint. That's where signing a request comes into the picture. This is only necessary in Chrome right now but other browsers may also require this in the future.

This authentication works as follows:

1. You generate a public and private key once for your server. These are also called the application server keys. You might also see them referred to as VAPID keys. VAPID is the spec that defines this authentication process.

2. Every time you subscribe a client to push notifications, you provide your public key. The push service associates this public key with the endpoint it generated for the device.

3. When you send a web push protocol request, you sign some JSON data with your private key.

4. When the push service receives the request, it uses the stored public key to authenticate the signed information. If the signature is valid then the push service knows that it has indeed come from your server (Make sure your Private key is not leaked otherwise anyone can sign requests on your behalf).

Customize the delivery of the push message

The web push protocol request specification also includes parameters that allow you to customize the push service's message delivery attempts to the client. For instance, you can modify:

• The Time-To-Live (TTL) of a message, indicating how long the push service should try to deliver a message.

• The message urgency, which is beneficial if the push service is conserving the client's battery life by only delivering high-priority messages.

• The message topic, which replaces any pending messages of the same topic with the most recent message.

Receive and display the pushed messages as notifications

The push service delivers the message to the user as soon as he is online. When a client's browser receives the message, it decrypts the message and dispatches a push event to your service worker. A service worker is just a javascript code that can run in the background even when your website is not open.

In the push event handler of your service worker, you need to call ServiceWorkerRegistration.showNotification() to display the message as a notification. The SeviceWorkerRegistration can be accessed through self.registration.

Conclusion

We've covered a lot of ground in understanding how web push notifications work under the hood. From getting permission to subscribing the client, encrypting the message, authenticating requests, customizing delivery, and finally handling the push event to display the notification - it's a multi-step process that might seem daunting at first.

But don't worry, in the upcoming articles, I'll provide a complete code walkthrough to implement web push notifications step-by-step. We'll dive into the nitty-gritty details, explore some helpful libraries, and get our hands dirty with code examples.

By the end, you'll be a web push notification ninja, ready to engage your users even when they're not actively browsing your website. Just remember to use this power responsibly and avoid going overboard with spam notifications that'll send your users running for the hills.

So stay tuned, grab a cup of coffee (or beverage of choice), and get ready to level up your web game with the magical world of push notifications!