Desktop & Mobile App Sessions

The Desktop and Mobile Apps use browser-based sign-in to apply your site's authentication requirements, including Single Sign-On and two-factor authentication. After you authenticate, the app receives a dedicated credential that keeps it connected with your permissions. Collecting and first using that credential are subject to checks separate from optional session IP pinning.

The App's Ongoing Authority

The browser establishes the user's identity under the site's password, SSO, and 2FA requirements. The app then uses its dedicated user credential for file work. It does not ask the identity provider or request a second factor before every read or write; that would prevent background transfers and ordinary file-system use.

These app credentials are separate from keys users create for their own integrations. Turning off Allow Users To Create API Keys does not prevent Desktop or Mobile sign-in. The separate Desktop App Session Lifetime and Mobile App Session Lifetime settings control when users of each app must authenticate again. App credentials remain tied to the user's permissions and enabled account.

The initial exchange must connect the browser's completed sign-in to the app that requested it. Different app generations establish that relationship differently, which is why an IP-address condition for an older sign-in flow should not be treated as a universal app requirement.

Pairing-Based Sign-In

The Mobile App, Desktop v4, and older Desktop v6 releases use a temporary pairing key to associate browser sign-in with a pending app connection. After authentication, the app can collect its credential only once, within 60 seconds of the credential's creation, and from the same public IP address as the browser. The time limit begins after authentication creates the credential, so it does not limit how long you have to complete SSO or two-factor authentication.

Desktop and Mobile credentials issued this way must also make their first connection from that same address within one minute of creation. Collecting the credential does not restart the clock. If its first connection is too late or comes from a different address, the credential is invalidated and a new sign-in is required. These conditions apply regardless of the connection protocol.

Desktop v6 Sign-In

Current Desktop v6 releases use OAuth with Proof Key for Code Exchange (PKCE). Completing sign-in requires proof retained by the app that started it, and the browser returns authorization through a local connection on the user's computer. This allows the browser and app to use different outbound IP addresses, such as when they use different corporate proxies. The new app credential must still be used within one minute of creation.

Address Checks and Session Settings

The Desktop App's proxy selection determines which network route it uses. The browser and app can use different routes, so address checks need to account for the sign-in method as well as the network configuration.

The address Files.com observes can be shared by several devices behind a router, VPN, or proxy. Matching addresses do not establish that requests came from the same physical device. When comparing connections, two different devices on a shared network may still have the same public IP address.

Desktop Session IP Pinning adds an address restriction after sign-in. It is disabled by default so users can change networks without repeatedly signing in. Disabling it does not remove the initial sign-in checks described above. The app session lifetimes independently determine how long each sign-in remains valid, regardless of activity or whether the address stays the same.

Session Lifetime and Device Removal

The default lifetime is 180 days (4,320 hours) for Desktop App sessions and 30 days (720 hours) for Mobile App sessions. Each lifetime is measured from sign-in. Changing one does not change the other, so an organization can set a different sign-in frequency for computers and mobile devices.

The configured lifetime applies when a credential is issued. Reducing it does not shorten an existing credential's expiration, and reconnecting with that credential does not issue a new one. Setting either lifetime to 0 makes new sessions for that app expire immediately; it does not revoke existing sessions or affect the other app. These rules also apply when lifetimes are enforced through a Child Site Management Policy.

To end an existing Desktop connection, a Site Administrator uses Active Desktop Connections. Disabling the user ends access through that user's credentials more broadly.

To end all sessions for one app across the site, turn off Desktop App Enabled or Mobile App Enabled. This also blocks new sign-ins to that app, including for administrators. The other app and web sign-in, including SSO, remain available. Re-enabling the app permits fresh sign-ins but does not restore revoked sessions. These rules also apply when a Child Site Management Policy disables an app.

An app's Files.com session is separate from information already saved on the device. Revoking access prevents further authorized use of Files.com; it does not remove downloaded files or copies kept by other applications. Device offboarding needs to address those local copies as well as the server-side connection.