Introduction
UnifiedPush is a protocole that allows you to get push notifications, while letting the user choose the provider they wish to use.
In this ecosystem, we can identify 2 differents sides:
- The push provider, who provides an application responsible to keep a connection with its server, and to forward notifications to other apps. This is the push service, also named distributor, which works with its push server. The push server receives messages from other applications.
- The end user applications, the applications that consumes the push service. Their server send messages to their mobile application through the push server and the distributor.
Any application can be used with any distributor. The application will pick the user installed distributor, or ask what they wish to use.
ImportantWhen adding support to UnifiedPush, you should try the feature with at least 2 different distributors!
Push notification is a misleading name, it gives some confusion with notifications shown on the user interface. Push message would be more accurante: they don’t necessarily lead to a notification. They can be used to wake your client to synchronize with the server, or to process the content in the background.
Push notifications are encrypted following RFC8291. The application generates a public key and an authentication secret it shares with its server with the endpoint. So the server can use these informaiton to encrypt the notifications. UnifiedPush libraries generate these keys when they register for a new registration, and decrypt automatically incoming notifications. So it is pretty transparent for the developers. On the server side, it is recommended to use webpush libraries, no matter your framework or your programming language, there should be one available.
ImportantSome libraries are outdated and support a draft of the RFC8291 (the 4th draft) and won’t work. To check if the library supports the RFC correctly, check thecontent-encodingheader: it must beaes128gcm.
Push notifications may be authenticated with VAPID (RFC8292). VAPID is a mechanism to authenticate requests to a push server, using asymmetric keys. These keys are generated by the application server. The mobile application fetch the public key and use it to register to the distributor, which will be able to add restrictions for your subscription. VAPID adds an additional security layer on push notifications, endpoints are already Capability URLs that should not be guessable.
ImportantSome push providers require a VAPID key to get registrations, if they don’t have it, they will respond to registration with a failure.
Some other push providers may ignore VAPID authorizations.
A blog post gives more details about security of push notifications.
The content of the cleartext of the notification is then totally dependent on the application. It may be a json containing the information that can be used to create a UI notification directly, a simple ping to tell the app to synchronize, a message the app needs to parse, and so on.
ImportantAfter receiving a registration, it is recommended for the application server to send a unique token to the application, that it will send back to the app server. The app server will use the new registration only once it is validated with the token.
The application server should deny by default endpoint to non-global IP. If the app server is self-hostable, then a parameter should be provided to allow some origins.
If you wish to add UnifiedPush to your application, you are probably looking for being able to receive notifications using an external distributor. Then you can look at the Implementations if a library is available for your framework, programming language and your plaform.
If you wish to write a new distributor, to provide push notifications to other applications, you need to look at UnifiedPush specifications, starting with the Definitions.