Desktop and Mobile App Sign-In
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 Desktop/Mobile Session Lifetime controls when app users 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 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 Desktop/Mobile Session Lifetime separately determines how long an established app session remains valid.
Session Lifetime and Device Removal
The configured app 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. 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.
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.