Azure Blob Storage SAS Expires Early

1
votes

We have an ASP.NET Core v1.1 web application that displays protected images stored in the Azure Blob Storage Service. We achieve this by using a Shared Access Signature (SAS) that expires 36 hours in the future.

We store this SAS in memory for up to 18 hours (sliding expiration of 6 hours, absolute expiration 18 hours), to avoid repeated calls to the blob service. This has been in production since October, without issue, but recently over the past week we have run into issues where our customer is reporting broken images. Clearing the cache fixes the issue.

Our short term workaround is to shorten the cache to a maximum of 5 minutes, but I'm not sure why we would need to if the SAS is valid for 36 hours?

So, my questions are:

  • is it possible for a SAS to expire much earlier than expected?
  • is it safe to cache the SAS like I described, or should I request a new signature for every single request?
1
azure-storage-blobs

1 Answers

-2
votes

When you use shared access signatures in your applications, you need to be aware of two potential risks:

  • If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.
  • If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then the application's functionality may be hindered.

This describes the best practice for using SAS Token - Best practices when using SAS

As mentioned in the that Use near-term expiration times on an ad hoc SAS and have clients automatically renew the SAS if necessary. The key consideration is to balance the need for the SAS to be short-lived with the need to ensure that the client is requesting renewal early enough.