What's New in the Apple Push Notification Service

Welcome to the session 724 on What's New in Apple Push Notification Service. My name is Mayur Mahajan. And I work on the Apple Push Notification Service, or APNS. And I'm excited to share with you what's coming to APNS. Let's get started with a review of important enhancements that were released last year. First, we introduced a brand new provider protocol based on HTTP/2 persistent Pushes. HTTP/2 is a binary protocol that supports multiple streams over a single connection and is extremely fast. The new protocol has made it very easy to send Push notifications to their devices. The new protocol supports providing instant feedback to indicate which device tokens are no longer active.

It is also possible to send larger payloads, up to four kilobytes, that you can take advantage of for creating rich applications. In addition, we'll simplify the certificate handling so you will now have to maintain fewer client certificates used to connect to APNS. We have received a lot of positive feedback from the developer community.

We deliver hundreds of thousands of notifications per second using this new protocol. If you are not using this already you should definitely try it.

So let's recap the sequence of steps that are involved in sending Push notifications. On the bottom right is your client application. And on the top right is the provider, which is the server component that connects to APNS and sends Push notifications.

Now, before you start sending notifications, you should register for Push notifications in the developer account. The application will register with the operating system, running on the device on the bottom left.

The device will request a token from APNS on behalf of the application. And then return it back to your application. This device token will be unique for your application running on this device. Your application should forward this token to the provider.

Now, the provider service will connect to APNS using the client certificate and then use standard HTTP/2 post request to send a Push to that device token.

HTTP/2 provider API will provide an immediate response indicating success if everything was okay. And APNS has received and validated that the Push request is . Now, if there was an error, say the device token is not valid, APNS will return an error status 400, or "invalid request" with adjacent payload indicating the reason. For example, a bad device token. The new provider protocol also provides instant feedback. So if a device token has been removed, you will get an HTTP/2 response with status 410, or "removed." It will have a time stamp in payload indicating when APNS last learned that the device token has been removed.

We also simplified certificate handling as part of the new provider protocol.

You can now provision a single certificate for your application, complication, and VoiP Pushes. The same certificate can be used in both development and production environments.

This has reduced the headaches of managing, renewing and revocation of multiple certificates for many developers. Now, we are listening to feedback from developers like you. And we understand the importance of simplifying the work flow that's involved in sending Push notifications.

We understand that managing certificates is too complex for some applications. So today we are thrilled to announce a brand new and a simple way of authenticating against APNS.

Introducing token authentication for Apple Push notification service. Token authentication is a way of using provider tokens instead of client certificate when sending notifications.

The authentication tokens are intended to simplify how services connect to APNS. In addition, the tokens are easy to generate programmatically, so there is no need to worry about having to reissue expiring certificates.

This is enabled through the use of JSON Web tokens as a mechanism to generate authentication credentials. There are a number of libraries widely available for use with the programming language of your choice to generate these tokens. Now, before we get into the details of how token authentication works, let's first recap how certificate authentication will work.

You opt in. Provide a client certificate from your developer account.

When connecting to APNS using mutual authentication, APNS will provide a server certificate that you will trust and validate. As part of the handshake, your provider will also sign the client certificate, which APNS will validate and use to establish credentials. At this point, there is a trusted connection established between APNS and the provider.

Any Pushes you send on this connection are attached to the application identified by the client certificate.

When using token authentication, you should opt in a token sign-in key from the account.

Your provider will then establish a PLS connection without a client certificate. However, before sending notifications on this connection, the provider will construct an authentication token that includes your team ID. And then sign it using the key opt indicator.

Now it's possible to send notifications on this connection.

Every notification message that's signed must include the authentication token.

Also, the application topic should be part of this request. APNS will first authenticate the provider using the token and then process the request. If this request is processed successfully, APNS will send a response back indicating success. If no token was provided with the request or if the token was invalid, a response will be sent back indicating the error. As a reminder, APNS will not close the connection on error.

So let's take a look at how to generate a provider token.

You should start with provisioning a sign-in key from the certificates, identities and profile section in the account. A public-private keypad is generated. And the private key can then be used to cryptographically sign the token data.

Apple will use the corresponding public key for validating the token. Next, let's look at how you construct the token. At the top is an example of what a JSON Web token that's part of the request might look like.

Let's go over the structure of this JSON Web token.

You can see it has three parts. Each part is a URL friendly base-64 encoded string that's delimited by a period.

Below is the decoded representation of this Web token. The first part is the header.

And it includes attributes that specify the algorithm used to sign the token. In our case, it's ES256. It will also include the key identifier for the key that is used to sign the token. The claims section will include an assurer tribute, which is your developer team ID that can be obtained from the account. The next attribute in the claims is initial time stamp that's expressed as seconds since epoch.

The last part of the token is simply the signature in base 64 obtained by applying the signing algorithm to the header and the claims.

This prevents any unauthorized tampering of the token once it is generated.

Here is what an HTTP/2 creates for a request using token authentication will look like.

As you can see, this request contains a header and a data frame. The header frame consists of various header fields including APNS topic.

Now, you will notice that the header frame now includes an authorization header with the value "bearer" followed by the signed provider token. If the request including the authentication token is valid, the response will be status 200 or "OK." Here is what the response will look if the provider token was not valid.

In this case, it is status 403, or "Forbidden." Now, APNS will require that new tokens be periodically generated. If the token is too old, the response will, again, be a 403 "Forbidden" error with reason indicating that the token has expired. APNS will require that the token creation time must be within the last hour. However, a new token should not be generated on every request. In fact, for performance we recommend that the token be reused as long as it is valid.

So here are a few more details regarding token authentication.

As mentioned earlier, the provider tokens need to be generated periodically. However, note that the sign-in key does not expire.

Now, if you suspect that the sign-in key may have been compromised, you can revoke the key from your account and provision a new key. As a reminder, APNS will continue to support certificate authentication. So that is token authentication. And it's coming later this year. For more information visit the Website for this session at developer.apple.com/wwdc16/724.

Here are relevant sessions on notifications that you might be interested in: Introduction to Notifications will be in Pacific Heights on Wednesday at 9:00 a.m. followed by a session on Advanced Notifications in Pacific Heights on Wednesday at 10:00 a.m. And we hope to see you there. Thank you very much.