Shared access signature correct way to share documents

*anonymous user* Though not a recommended practice, it is possible to create a SAS which never expires. To achieve this, you don’t specify the expiry date when creating SAS. In the earlier version of storage service, only revocable SAS can be never expiring, and anonymous SAS are only valid for 1-hour duration. However, with the latest version of storage service, it is possible to create never expiring anonymous SAS.
https://stackoverflow.com/questions/52547152/default-start-time-and-expiry-time-for-an-account-level-sas-token

There are two ways to set expiry on SAS. The first is to build it into the SAS token itself. Then the only way to check expiry is to inspect the se= parameter of the token. You could maintain a list of known SAS tokens and alert based on the expiry.

The second way to set expiry is to set it in a stored policy on a container. Then the SAS token would reference it using.

​You can check the expiry in that case using the Get Container ACL API (sometimes called GetPermissions).

​You would need to check each container that may contain a policy and alert based on the time set in the policy.

If you want to know if your account-level SAS is expired or expiring of , based on this doc , you can just check the SignedExpiry param. in SAS , its name is se.

https://free.blessedness.top/en-us/rest/api/storageservices/create-account-sas#specifying-account-sas-parameters

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.

You may create some application to save the expiry date every time you create one SAS, and with this you may have some alters from that application, but Azure don’t support this feature.

Additional information: Have clients automatically renew the SAS if necessary. Clients should renew the SAS well before the expiration, in order to allow time for retries if the service providing the SAS is unavailable. If your SAS is meant to be used for a small number of immediate, short-lived operations that are expected to be completed within the expiration period, then this may be unnecessary as the SAS is not expected to be renewed. However, if you have client that is routinely making requests via SAS, then the possibility of expiration comes into play. The key consideration is to balance the need for the SAS to be short-lived (as previously stated) with the need to ensure that the client is requesting renewal early enough (to avoid disruption due to the SAS expiring prior to successful renewal).

Best practices when using SAS: https://free.blessedness.top/en-us/azure/storage/common/storage-sas-overview#best-practices-when-using-sas

Lifetime and revocation of a shared access signature

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.