Access Key vs. Shared Access Signature (SAS) Token

Files.com can connect to Azure Blob Storage using a storage account access key or a Shared Access Signature (SAS) token. An access key grants broad storage account access. A SAS token limits the resources, operations, and validity period available to anyone holding it; it is not inherently tied to a particular Files.com user.

Use a token scoped to the resources and operations the integration needs. Protect either credential as a secret. Follow Azure's SAS guidance when choosing its lifetime and permissions.

Credential Rotation

Files.com uses the key or token saved on the Remote Server. Replace a SAS token before it expires, and update the Remote Server before revoking an old access key. A SAS token does not refresh itself. Choose an expiration period your organization can support with a reliable rotation process.

An expired or revoked credential causes dependent Mounts, Syncs, automations, and transfers to fail until you replace it. Review failed or partially completed runs after restoring access; some files may already have transferred. Do not wait for an expiry-related outage to rotate the credential.

SAS Token Permissions

A SAS Token carries only the permissions you grant when you create it, so the token must include every permission Files.com needs for the operations you intend to perform. An Access Key always grants global, root-level access and cannot be narrowed, so a SAS Token is the only way to give Files.com least-privilege access to your Blob storage.

You can create a SAS Token at three scopes: an account SAS for the whole storage account, a service-level SAS for a single container, or a folder-level SAS for a single folder within a container. Scope the token as tightly as the integration allows. A service-level SAS on the container Files.com connects to is the usual choice, and a folder-level SAS is narrower when Files.com uses only one folder. An account SAS works but grants the broadest access.

An account SAS is signed with the storage account key. A service-level or folder-level SAS can be signed with either the account key or a user delegation key. A user delegation SAS is limited by the permissions of the Microsoft Entra identity that obtained the delegation key as well as the token's permissions. Its lifetime cannot exceed that of the delegation key, which is at most seven days. Account-key-signed tokens have different authorization and revocation rules. Choose a supported scope and signing method together with a rotation process.

When you create an account SAS, set Allowed services to Blob and Allowed resource types to both Container and Object. If any of the three is missing, Azure rejects operations with a service or resource-type mismatch error. A service-level or folder-level SAS does not expose these settings in the Azure portal and applies the equivalent scope automatically.

Grant one of the following permission sets based on how Files.com will use the container.

Full Access

Full access lets Files.com perform create, read, update, and delete operations on the container, including renaming, moving, and copying files and folders. Use it when Files.com both uploads and downloads, synchronizes folders, or manages data through Syncs and automations.

Grant Read, Write, Delete, and List, which appear on the token as sp=rwdl. These four permissions cover every operation, including rename, move, and copy. The Create permission that the Azure portal also offers is not required, because the Write permission already covers adding new files.

On a container with a hierarchical namespace (Azure Data Lake Storage Gen2), the Azure portal offers extra permissions in the SAS form, including Move. Files.com does not require any of them, because it carries out renames, moves, and copies without using Azure's native Data Lake move operation. The same rwdl set grants full access on both standard and Data Lake containers.

Read-Only Access

Read-only access lets Files.com list and download files without changing anything in the container. Use it when Files.com imports data or provides read access to files but must not upload, overwrite, or delete.

Grant Read and List, which appear on the token as sp=rl.

When you scope the token to read-only, also set the Files.com users with access to this container to read-only folder permissions, so that the storage-side scope and the Files.com-side permissions match.

Write-Only Access

Write-only access is a drop-off mode. Files.com uploads files into the container but cannot download, rename, move, copy, or delete them. Use it for one-way delivery that does not require reading files back. Write permission can also overwrite an existing blob, so this permission set alone does not enforce immutability.

Grant Write and List, which appear on the token as sp=wl. The Write permission lets Files.com upload files. The List permission is required as well, because Files.com lists the uploaded file afterwards to confirm it was written correctly, and without List that confirmation fails with an authorization error.

Azure RBAC and SAS Permissions

For account-key-signed SAS tokens and direct access keys, Microsoft Entra RBAC assignments do not narrow the key's data access. A user delegation SAS is different: access is limited by both the token and the issuing identity's permissions. Configure the token permissions and any applicable identity permissions together.