Uploadcare allows users to easily upload files from a growing number of social networks and cloud services. Which raises the obvious question — is it safe? And can others read or even modify user files that are not uploaded to Uploadcare but stored in cloud services? To answer all of these questions, we’d like to explain how Uploadcare works with third-party services.
All interaction with services is done over to Service” button in the OAuth or OAuth2 protocols. The way they operate is roughly the same:
- The user clicks the Connect to Service button in the Uploadcare widget. A new tab or window of the selected social network or cloud service is opened.
- The service asks the user to enter his or her username and password on its website. This step may be skipped if the user is already logged into the service.
- The service requests permission to provide Uploadcare access to its data. This step may be skipped if the user has previously allowed access to their data.
The service provides Uploadcare with a key, so-called “access token.”
Uploadcare uses the access token to access user data.
The service doesn't provide Uploadcare with user credentials. Users can revoke access from Uploadcare at any time (this is done on the service side, usually in account settings).
The authorization and file selection is implemented in the widget but actually occurs within the iframe. An iframe is an HTML element that allows one to open documents from a different domain from within a current document. Thus an external site on which the widget is installed cannot receive any events or data from a document containing a user files list. The only event that occurs in the widget itself is the user’s selection of a particular file.
Even if the site owner on which the Uploadcare widget is installed is ill-intentioned, he or she cannot actually get a list of user files or any other form of access to them. The only files he or she has access to are those that have been explicitly chosen by the user. The same rule applies if the site owner uses his own application for the service.
It sounds weird, but it’s true. We understand that there always remains a remote possibility of server hacking. If someone gained access to an application server that stores access tokens of a large number of users (a reference to one of our competitors goes here:), he would then have access to all the files stored in the cloud services of those users. Which is why we do not store access tokens in any way, shape, or form. Instead, the access token is passed along to the server with each request. The only one who can access his files is the user himself.
Our service works via the SSL protocol. This means that all traffic between the user’s browser and our servers is encrypted, so the attacker will have difficulty obtaining the access token from queries. But still, the access token is the key that provides full access to user files and thus should not fall into the wrong hands even when data is successfully intercepted. Due to this, we further encrypt the access token passed in the request so it cannot be used anywhere but on our own server.