- Since publishing "FCM HTTP v1" Google improved security system of their FCM services. Now it requires to use short-time access tokens from OAuth 2.0 service, which uses private key based authentication and specific Google software libraries.
- Each terminal vendor has it's own application with it's unique Application ID registered and Google Firebase. Terminal may have several applications with different IDs. It should not be a good idea to hardcode Application IDs inside BM's code as well as vendor's private key to pass Google Authentication.
- Due to real-time nature of the service all messages should be sent by BM directly. This should solve issues of inaccessability of service and power of vendor's site.
- When terminal goes to the idle mode it may pass IDLE message to BM contains info about Vendor's service which will provide information to pass messages to FCM such as application-id, access-token, expiration-time.
- On this way terminal vendor delegates message sending feature to BM without disclosing information of its private keys.
- BM / Registry will store these data and assosiate it with particular terminal / connection context and use it to wake application up.
- Terminal sends to BM a messasge REWIND_TYPE_TERMINAL_IDLE that contains string in then next format: FCM-HTTP-v1 <URL of token service> <device token>
- BM checks local database for suitable access token and application ID *A1
- BM sends push message to terminal using suitable access token and application ID
A1. Token information not found:
- BM queries <URL of token service> for application and token info
- Token Service does authentication at Google OAuth 2,0 service using its private keys
- Token Service passes pplication-id, access-token and expiration-time to BM
- BM stores token access token and application ID in database
- Should vendor's token service do validation of BM?