Concerns with both approaches
1)
It would be possible to register new devices, if the pub/private key (or the accessKey:secret combination) would be hacked.
HOWEVER, the "hacker" has to know how to generate VALID tokens for the different push-networks. Apple and Google will NOT accept incorrect tokens, and IMO this as a minimal risk.
Similar for SimplePush. The SimplePush Network/Server, generates UUIDv4 key, for every channel, so IMO.... it's hard to "hijack" that as well.
=> But I may be just naive.
1a)
would perhaps,... add some "monitoring" if an unreasonalble about of "new devices" is registered, but that means we need some sort of analysis component (not for the first iteration) :)
2) hacker can update device info
If the pub/private key (or the accessKey:secret combination) are being compromised. it is possible to update informations for a certain device. IF... he know the "token".
So... it's than very simple that the hacker can update informations for his phone (since that token is VERY easy to read, via the platform APIs).
IMO not a big deal. If he updates his iPhone metadata (e.g. changing "iOS" to "Android"). If he changes his token, he looks himself out -> No longer receives "push notification messages"
2a)
A hacker could update device infomations for other devices. BUT !!!! he has to know the token of other devices, registered with our server. This means, he needs access to those devices.
=> IMO as well not a big risk..
Summary:
I think, if we really have a "extra" pub/private key (or the accessKey:secret combination) for "device (un)registration", and not allowing this pub/private key (or the accessKey:secret combination) on other HTTP calls (e.g. register Push Application, register mobile Varian, sending): The risk is IMO minimal.
Thoughts ?