Open yakovyarmo opened 4 days ago
Hello, although up until today I have never thought about Broadcast Channel
on Android, I would like to take the opportunity to explain Apple Login on Android, and the challenges associated with it.
Firstly, Apple login on Android will always require a backend server. Period. This is a STRICT requirement from Apple. Nevertheless, intent handling on Android was a conscious design decision from my end. Martin strongly opposed it.
I understand that it may be inconvenient, however it often simplifies the login for the end user. Before intents, this plugin was using a webview. Using a webview was less secure; however, it was easier to implement in any app as it did not require custom intents. However, using a webview did not allow the usage of logging in via a device (instead of a password) or saving the password.
Currently, the plugin opens the login page in Chrome. This means that we have no control over the behavior of the browser. I am happy to explore broadcast channel on Android, as long as the implementation doesn't compromise the security of the end user or their experience.
Please let me know if a broadcast will redirect the user back into our app from Chrome. If it does, I would love to explore this further. However, if a broadcast is not possible to be send from Chrome or if it doesn't redirect the user back to the app, then I do not see a place for it in the codebase.
I'd like to suggest using Broadcast Channel for handling the client-server communication during Apple Sign-In authentication, rather than the current approach which requires setting up intents and server-side URL binding.
Current Implementation:
The existing solution requires:
Proposed Change:
Using Broadcast Channel could offer several benefits:
Implementation notes:
Happy to hear your thoughts on this approach! 💭