Skip to main content
Version: 3.6.x.x RR

Push notifications

One of the ways of delivering messages from the Nevis Mobile Authentication backend to the mobile application is to use the push notification channel. All out-of-band use cases can use this channel to involve the mobile application in any FIDO operation that is triggered from outside the mobile application.

The Nevis Mobile Authentication SDK provides an API which is responsible for registering, updating and deregistering push notification capabilities with the Nevis Mobile Authentication backend. Any interaction with the push notification provider is managed separately by the mobile application. Typically, a dedicated SDK is used to ease integration with the provider. The following figure shows how the registration token is transferred from the push notification provider to the Nevis Mobile Authentication backend.

Transfer of push token to the Nevis Mobile Authentication backend
caution

It is up to the mobile application to ensure that any changes linked to the registration token are also correctly reflected in the Nevis Mobile Authentication backend.

As an added security measure, push notifications are encrypted when transiting between the Nevis Mobile Authentication backend and the Nevis Mobile Authentication SDK.

info

The supported push notification provider is Firebase Cloud Messaging. For additional client-relevant documentation regarding the integration of FCM into a mobile client application, see the official Firebase documentation.

The next sections describe the processes that are involved in authentication with push notifications.

Register push notifications

As a prerequisite, a registration token must be retrieved from the push notification provider. The provider uses this token to send push notifications to the mobile application. To retrieve the registration token, the mobile application can integrate the SDK developed by the push notification provider. The Nevis Mobile Authentication SDK is not involved in this step. Once a valid registration token is obtained, the mobile application can pass it to the Nevis Mobile Authentication SDK, which registers the token in the Nevis Mobile Authentication backend.

There are the following options for registering the token in the Nevis Mobile Authentication backend:

  • During a FIDO Registration, the Nevis Mobile Authentication SDK can piggyback the registration token with the FIDO Registration operation. This is the recommended approach.
  • The Nevis Mobile Authentication SDK provides an API to register the token with the Nevis Mobile Authentication backend. Note that if this option is chosen, the mobile application must have completed a FIDO Registration first. This API calls an endpoint requiring a FIDO Authentication, which also triggers the user verification process. This option is not recommended.
tip

The advantage of the first option is that the user only needs to go through the user verification process, which is needed by the FIDO Registration operation, one time. The second option results in two user verification processes: One for the FIDO Registration and one for the token registration with the Nevis Mobile Authentication backend. This means that the second option results in a bad user experience. Nevertheless, the second option is useful if the user decides to enable push notifications later, without going through a complete new FIDO Registration.

During the push notification registration process – regardless of the chosen approach – an exchange of two public keys takes place. One key is used by the Nevis Mobile Authentication backend to encrypt the push notification, to ensure that only the SDK can read it. The Nevis Mobile Authentication SDK can then decrypt this encrypted push notification and process it. The other key that is exchanged, is used to sign the payload, to update the registration token without requiring user verification.

Naming the device

When configuring the push notification, it is also possible to define the device name. The name is used by the Nevis Mobile Authentication backend to inform the user where the push notification is supposed to be sent. Device name does not allow emoji characters, if the Nevis Mobile Authentication backend system is used as part of the Software Delivered solution.

Consuming push notifications

Push notification consumption

If the registration token is saved successfully in the Nevis Mobile Authentication backend, the mobile application is able to receive push notifications.

The mobile application consumes the push notification, and reads the encrypted raw content. The encrypted raw content is then forwarded to the Nevis Mobile Authentication SDK. From there on, the SDK takes over the work. The raw content is decrypted by the SDK to proceed with the containing FIDO operation.

Updating push notifications

The registration token can transition to an invalid state in the following cases:

  • The app deletes the instance ID.
  • The app is restored on a new device.
  • The user uninstalls or re-installs the app.
  • The user clears the app data.

In any case, if the registration token is no longer valid, the mobile application must retrieve a new one and must ensure that the Nevis Mobile Authentication backend is informed by the change. If the backend does not know the new registration token, the application does not receive new push notifications anymore. The mobile application should use the SDK of the push notification provider to get notifications of the registration token update.

By contrast with push notification registration, user verification is not triggered to update the registration token. This update must take place automatically in the background without any user interaction. As an added security measure, the payload to update the registration token is signed with the private key, that was generated during the token registration process.

Deregistering push notifications

Deregistering the registration token on the Nevis Mobile Authentication backend is useful in the following cases:

  • If the user does not wish to receive push notifications on the device anymore, but wants to continue using the mobile application.
  • As a housekeeping task, if the user deregisters an authenticator with push notifications. In this case, the mobile application should deregister push notifications before deregistering an authenticator.

The endpoint of the Nevis Mobile Authentication backend that is used to deregister push notifications is protected and requires a FIDO Authentication.