what is differance between SAS Connection string and SAS token

manish verma 441 Reputation points
2020-06-24T10:02:34.653+00:00

Hi All,

we are develop a .net application to upload file in Azure Blob. we are using SAS connection string.

my application is working fine.

Now few people ask me to use SAS token instead of SAS connection string. we want to know is any security issue with SAS connection string. what is best practices in this case to select between SAS token vs SAS connection string

Azure Storage Accounts
Azure Storage Accounts
Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
2,906 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Sumarigo-MSFT 45,406 Reputation points Microsoft Employee
    2020-06-24T10:32:00.717+00:00
    • A connection string includes the authorization information required for your application to access data in an Azure Storage account at runtime using Shared Key authorization. You can configure connection strings to:

    Connect to the Azure storage emulator.
    Access a storage account in Azure.
    Access specified resources in Azure via a shared access signature (SAS).

    To learn how to view your account access keys and copy a connection string, see Manage storage account access keys.

    We can use the SAS in a connection string. Because the SAS contains the information required to authenticate the request, a connection string with a SAS provides the protocol, the service endpoint, and the necessary credentials to access the resource

    For more information on connection string, please refer here: https://learn.microsoft.com/en-gb/azure/storage/common/storage-configure-connection-string#create-a-connection-string-for-an-azure-storage-account

    • A shared access signature is a signed URI that points to one or more storage resources and includes a token that contains a special set of query parameters. The token indicates how the resources may be accessed by the client. One of the query parameters, the signature, is constructed from the SAS parameters and signed with the key that was used to create the SAS. This signature is used by Azure Storage to authorize access to the storage resource.

    The SAS token is a string that you generate on the client side, for example by using one of the Azure Storage client libraries. The SAS token is not tracked by Azure Storage in any way. You can create an unlimited number of SAS tokens on the client side. After you create a SAS, you can distribute it to client applications that require access to resources in your storage account.

    When a client application provides a SAS URI to Azure Storage as part of a request, the service checks the SAS parameters and signature to verify that it is valid for authorizing the request. If the service verifies that the signature is valid, then the request is authorized. Otherwise, the request is declined with error code 403 (Forbidden).

    For more information, please refer to this article: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview

    10577-capture.jpg

    SAS keys are for REST access and mainly just for API/programmatic access.

    Account SAS does not have a SignedResourceTypes (srt) parameter, which is required(see documentation)

    Additional information: There benefits for this is:
    • No long lived SAS tokens
    • You can do key rotation
    • You can move, upgrade or change storage accounts without informing your customer base (which is a big deal with you have thousands of uploads)
    • Avoids FTP or other technologies which requires servers
    • This will also raise an event based upon a “marker” file that indicates an upload is complete. Typically, many files are uploaded and you cannot trigger processing when you see the first file (plus the trigger is a blob created event and not blob “fully” hydrated/uploaded), you need to wait until you see an “end_file.txt” which means a series of upload have completed and you can start downstream processing.

    It does rely on a secret between the two parties:
    • If a vendor is uploading to a storage account owned by customer A, then they have a secret. Different customers have different means for sharing secrets. Some customers have a rotation policy via a REST API and others are less concerned since the tokens only allow uploads from a specific IP address.

    We do support IP based restrictions in SAS tokens.
    You can generate User Delegation SAS tokens using managed identities

    SAS tokens are generated by signing a set of parameters using the storage account access key. This can be done on the client if a user has the key, and so requires no permissions.

    To retrieve the storage account access key, the user needs “Microsoft.Storage/storageAccounts/listkeys/action” permission. There are also additional utility functions that can let a SAS token be generated by the storage resource provider. Those are covered by “Microsoft.Storage/storageAccounts/listAccountSas/action” and “Microsoft.Storage/storageAccounts/listServiceSas/action”.

    Best practices when using SAS

    Hope this helps!

    Kindly let us know if the above helps or you need further assistance on this issue.

    ----------------------------------------------------------------------------------------------------------------------------

    Please don’t forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    2 people found this answer helpful.