Push API - Authenticating to Push Service

[moresandeep]

Sorry if this is not the right place, I tried to send an email to the mailing list but kept on getting
[email protected] replies.

Also, let me apologize in advance if this has already been discussed.
I was going through the Push API specs and I was thinking about authenticating to the Push Service, specifically between User Agent and Push Service.
Currently, it looks like there is no way user agent can authenticate to the Push Service (and in turn to application server).

As of now anyone can pretty much subscribe to any and all push messages advertised by a Push Service (on behalf of application server), this will not only put extra load on the Push Service but it will also prevent it from letting in only select user agents. I can think of at-least two uses cases where this can be beneficial

1. Say you have an web-application (on application server ) and you only want to push messages to only your registered users.
2. If you want to roll your own Push Service and don't want it to be open to all.

In the following subscribe function
Promise<PushSubscription> subscribe (optional PushSubscriptionOptions options);

There is an optional parameter PushSubscriptionOptions, it appears that this Option is enforced on in-coming messages.

Maybe, a similar optional parameter such as Authentication can be added here to be passed on to the Push Service. Push Service can then check with
a) Application Server or
b) Application Server can share the auth. info. before hand or
c) Push Service can use a gateway in front to authenticate the Worker.

Authorization can also be added to this object if required.

Thanks !

[beverloo]

Thank you for your input! Messages can be send to a W3C list after you subscribe to the list. The readme of this repository shares the link where you can do so for the public-webapps list.

There currently exists an IETF draft for Voluntary Application Server Identification for Web Push, for which Martin also wrote a pull request to the Push API.

This draft defines two things: a mechanism for an application server to identify themselves to a push service, and a mechanism for a subscription to be associated with a given application server. The pull request exposes the ability to create this association through a new PushSubscriptionOptions.applicationServerKey member.

A push service could restrict usage by requiring the public keys of application servers (provided by both the user agent upon subscribing and the application server upon sending a message) to be registered in some sort of portal. This wouldn't be great from an interoperability perspective, but I understand that operational reasons may (at least initially) require this.

Please do note that you'll need to create your own user agent in order to satisfy your second use-case: allowing developers to select their own push service is a non-goal of the API. How you handle authentication requirements between the user agent and the push service in that case is largely up to you.

[moresandeep]

Thanks for a speedy response and the link to the IETF Draft (should have read it before) !

Section # 3 Subscription Association, mostly addresses my question and I really like the idea. The draft addresses concerns about protecting Application Server and liking subscriptions to application servers by using keys.

I am not clear on how a user agent identifies itself to the Application Server. Say, in a eCommerce website you would only want to push notifications to logged-in/authenticated users. What I was trying to say was that the User Agent could either pass an authenticated token [1] from cookie etc. or explicit credentials (stored in browser) so they can be subscribed. The Application server can then look into the subscription and send directed messages.

About my second use-case - agreed, is there a draft for this already or a plan to have a draft for this in the future ?

[1] The draft does talk about tokens but I am not sure whether they are access tokens that are already issued or custom tokens, apologies in case I misread it.

[beverloo]

The tokens described in the IETF draft (please just consider section 2.3) are meant for the application server to authenticate with the push service, as well as subscription association. Authentication of the user with your web app is separate from this.

After you create a push subscription using the W3C Push API, you get a PushSubscription object that you have to transfer to your server. You would normally use fetch() for this. Such a request will include all cookies and credentials you'd expect from on-page requests. Additionally, because you are issuing the request, you can include other application-defined data as well.

I wouldn't consider the bring-your-own-push-service scenario to be in scope of the Push API. The effects of multiple persistent connections, potentially controlled using JavaScript, have a disproportional impact on resource usage of many mobile devices. Consider that no mobile browser guarantees your page to continue to be alive after the user minimizes it. For cases where the page is in the foreground, you could consider using Web Sockets or similar.

[moresandeep]

After you create a push subscription using the W3C Push API, you get a PushSubscription object that you have to transfer to your server. You would normally use fetch() for this. Such a request will include all cookies and credentials you'd expect from on-page requests. Additionally, because you are issuing the request, you can include other application-defined data as well.

Makes sense now thank you.

[beverloo]

Cool. The mailing list would probably be more appropriate for these sort of questions in the future.

Someone could close this now? :-)

[moresandeep]

Oh ya, got to get the mailing list to work. Closing ..