Authentication & Credentials

People and unattended systems need different ways to prove their identity when they connect to Files.com. A person can complete a browser sign-in and a second-factor challenge. A scheduled transfer needs a credential its application can supply without someone being present. Administrators choose the account, credential, and permitted connection methods together so each connection has the access its work requires.

An account represents a person or machine and carries its permissions. Its authentication method determines how password and single sign-on access work. SSH keys authenticate that account over SFTP. A user API key acts with its associated account's permissions and can narrow them further. Site-wide API keys have no associated user and need separate care when granting and ending access.

For staff already using an identity provider, Single Sign-On keeps browser authentication with that provider. Two-Factor Authentication protects interactive sign-in; its requirements depend on the credential and connection method. Unattended integrations use separate machine accounts and keys so a human sign-in policy does not interrupt scheduled work.

Issuing a credential and ending its access are separate decisions. A key created for one integration can be revoked without replacing every other integration's key. Changing a password does not revoke API keys, and a site-wide API key does not end when its creator's account is disabled. Keep an identifiable owner and purpose for each integration credential, and use Key Lifecycle Rules when your organization requires automatic inactivity or expiration controls.

Login credentials prove who is connecting. A server host key or TLS certificate lets the client verify where it is connecting. GPG keys protect file contents. These checks serve different parts of a file exchange, even when they use similar cryptographic terms.