Continuing the discussion from Frequently Asked Questions:
Based on this answer, Insynchq servers have nothing to do with synchronization speeds, nor customers ever be affected if any–or all–Insync server were to go offline. Is that correct?
@Fastidious: Yes, that’s correct.
The Insync client mainly use our servers for auto-updates (Mac and Windows) and licensing. There’s a known issue in the client right now that if our server goes down, the client will appear to be offline (it’s a status issue), but it should still work and continue to sync despite the status.
@marte: How is the token passed from the Google server to the local Insync installation during first authentication?
Are you redirecting to a loopback IP address (directly from Google server to local installation) or your domain (Google server to your server to local installation)?: https://developers.google.com/identity/protocols/OAuth2InstalledApp
@Markus It passes through our servers and then to the client. Note that the token that passes through our servers is a one-time use token (generated by Google), which is used by the Insync client to exchange for a refresh token (via Google servers). The refresh token is the one that is stored in the client and used for continued authentication to the Google APIs.
Previously, we used an in-app browser for logging in (where our servers are not involved), but because of various issues, we resorted back to an external-browser-based login as the default method. You can still use a manual in-app method for logging in as described here.
1 Like
Tank you for the detailed answer @marte!
The alternative login method is even better than redirecting to a loopback IP address. Being able to copy/paste the token myself dramatically increases my trust that the refresh token will end up only on my local client.
I understand that the risk is low as Google would probably revoke the refresh token pretty quick if it was used from two different IPs, but the above method still makes me more comfortable using Insync.
1 Like