Transcript
[ 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
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.
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.
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.
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.
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
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,
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
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.