Starting with a review of the HTTP/2 based provider API, you will learn about an important new feature: Token Based Authentication. Learn to connect to APNs using authentication tokens for sending pushes via the HTTP/2 API, relieving you of the overhead associated with maintaining valid certificates.
[ Music ]
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
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 [inaudible].
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
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
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
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
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.