Authentication & Credentials

Authentication establishes which account or credential is connecting. A session lets that connection continue without asking a person to sign in before every action. Permissions then determine what it can do. These are separate responsibilities: a successful sign-in does not grant folder access, and changing the way a person signs in does not automatically retire every credential they already hold.

This distinction matters whenever people and unattended integrations use the same site. A person may authenticate through your identity provider, return through a Desktop App session, and also own an API key used by a scheduled transfer. Your sign-in policy, app-session lifetime, and API-key controls each govern a different part of that access.

Interactive and Unattended Access

Interactive sign-in can ask for a password, an identity-provider response, and a second factor. An unattended job needs a credential it can present without a person answering a prompt for each file. Files.com supports both patterns so that human verification and reliable automated work can coexist.

Choose the credential according to the job. An integration's independent API key should have its own permissions, purpose, and expiration or revocation plan. An employee's browser sign-in should use the organization's authentication requirements. Treating those connections as interchangeable can leave an integration running after you believe a person's access has ended.

Credential Handling

A credential delegates specific authority to whoever can present it. A user key acts within its user's access and the key's restrictions; a site-wide key has independent site and Workspace scope. A signed transfer URL instead permits a particular transfer for its own lifetime. Choose the credential for the authority the connection needs, including how precisely you need to replace or revoke it.

Credentials saved for connections to other systems have their own handling rules. Stored Credentials distinguishes write-only configuration from secrets or signed URLs that can appear in submitted requests, webhook logs, or client diagnostics. Permission to use a connection and permission to retrieve its secret are separate decisions.

Establishing, Continuing, and Ending Access

A new connection must satisfy the checks for its authentication method. An established session has a lifetime and can be invalidated by the account or credential controls that apply to it. Selected sensitive changes require re-authentication, which confirms the acting user again without granting any additional permissions.

Session expiration is useful for requiring another sign-in after inactivity or a defined app lifetime. Offboarding is a different decision: it requires ending the account, credentials, and shared access that should no longer exist. Identify whether you need to stop one device, one integration, or all access for a person before choosing a revocation action.

Information already delivered is a separate responsibility. Ending a Files.com session cannot erase a downloaded file, and an already authorized temporary download URL has its own lifetime. Account controls and your organization's handling of downloaded data need to work together.