Access Key vs. Shared Access Signature (SAS) Token

Both the Access Key and the Shared Access Signature (SAS) Token provide secure authentication and authorization for Azure. The right choice depends on your specific requirements. We recommend consulting your security team to determine the method that suits your needs.

The Access Key provides global, root-level permissions to your Azure Blob. It is the preferred method when your Blob is used solely by Files.com and does not need to share access with other users or solutions.

The Shared Access Signature (SAS) Token offers restricted, user-specific permissions to your Azure Blob. It is the preferred option when your Blob needs to be accessed by multiple users or solutions. The SAS Token allows more granular control over access, letting you limit permissions to specific parts of your Blob and better segregate data access.

Whichever you choose, the key or token must be long-lived. A long-lived key or token does not have an expiration date and must be manually revoked or expired when no longer needed. Your integrations remain functional until you explicitly revoke access.

If you implement an expiration date for a SAS Token, we strongly recommend a duration that matches the expected lifetime of the business process the integration supports. The default duration of a SAS Token created in the Azure Portal is only 8 hours, which is far too short for a business integration. For example, if you are using a SAS Token for a business process with a vendor you will transact with for one year, set the expiration date to be no shorter than that timeframe.

All connections and functionality to Azure cease to work once the key or token expires or is revoked. Expired or revoked keys and tokens cause Syncs, automations, uploads, downloads, and Remote Mounts to fail. Configure these features to only operate while the key or token is valid.

Any uploads, syncs, or automations in progress fail if the key or token expires or is revoked. Files being uploaded will not be partially delivered and must be re-uploaded from the beginning once the key or token is replaced. Syncs and automations in progress show a status of Partial failure, indicating that some files were successfully delivered before the key or token expired or was revoked. Depending on the configuration, syncs and automations may continue to trigger and will continue to fail until the key or token is replaced.

If a key or token is rotated, revoked, or expired, and you need to restore access to Azure, replace the key or token with a new one. Update the Remote Server with the new key or token to re-establish access to your Azure Blob.

Do not use keys or tokens with expiration dates unless you are prepared for the downtime at the expiration time and are willing to manually replace the key or token each time it expires.

If you're unsure, we recommend using a long-lived Shared Access Signature (SAS) Token because it provides more granular security controls.

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. Sign long-term integration tokens with the account key, not a user delegation key. A user delegation key ties the token to a specific Azure user and applies that user's permissions in addition to the token's own, so the token is limited by both. If that user is later off-boarded from Azure, or their permissions change, the signature stops working and the integration connection breaks. The account key is not tied to a user and keeps the connection stable.

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 when Files.com is a one-way drop-off point, such as an archive or a delivery pipeline that only ever adds files.

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 Roles Do Not Apply

Azure role-based access control roles, such as Storage Blob Data Contributor and Storage Blob Data Reader, do not govern this connection. Those roles grant access to Microsoft Entra (Azure AD) identities, and Files.com authenticates to Azure Blob Storage with an Access Key or a SAS Token rather than an Entra identity. Set the permissions on the SAS Token itself, using the permission information above.