How/When should I generate a Azure datalake g2 SAS-Token?

I'm working on a project in Python that uses the azure.storage.filedatalake module in order to upload files to my gen 2 datalake.

In my project I'm using the URL for these files (as they are mostly images I need to serve to a frontend webpage). In order to make sure only some users have access to some files, I'm using SAS-tokens on these files.

Seeing as SAS-tokens are supposed to have an expiration time, my idea is, that every time a user logs in to my system, a SAS token is generated and saved on their session. This token can last for example 6 hours. If they relogin to my site a new SAS is generated for them. However their old SAS will still be valid for another 6 hours, and that token is until then simple unused, but valid.

1. Is it a security concern that previously used SAS tokens still exist until their expiration, or just a non-issue and how its supposed to work?
2. Would it be better if each user got generated a SAS token personal to them, that lasted indefinitely?
3. Is there a security concern from me showing the users SAS token on the webpage-frontend? (As it is needed in the link for the file)

1. Yes, the security concerns are there until a SAS token expires. Use a user delegation SAS when possible. A user delegation SAS provides superior security to a service SAS or an account SAS. A user delegation SAS is secured with Azure AD credentials, so that you do not need to store your account key with your code.

2. Generating a personal SAS for each user is fine but lasting it for infinitely is not recommended. Even if you are doing that, you need to define a stored access policy for a service SAS. Stored access policies give you the option to revoke permissions for a service SAS without having to regenerate the storage account keys. Set the expiration on these very far in the future (or infinite) and make sure it's regularly updated to move it farther into the future.

   As per the best practices when using SAS, Use near-term expiration times on an ad hoc SAS service SAS or account SAS. In this way, even if a SAS is compromised, it's valid only for a short time. This practice is especially important if you cannot reference a stored access policy. Near-term expiration times also limit the amount of data that can be written to a blob by limiting the time available to upload to it.

3. Yes, showing a SAS token on webpage-frontend might lead to security concern and may result in expose of your sensitive data. If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.

You can generate the SAS token by following below path:
Settings => Shared access signature => Select the options required and click on generate SAS and connection string and copy the SAS token.

When to use a shared access signature?

Use a SAS to give secure access to resources in your storage account to any client who does not otherwise have permissions to those resources.

A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. In a scenario where a storage account stores user data, there are two typical design patterns:

1. Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service allows the validation of business rules. But for large amounts of data, or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.

2. A lightweight service authenticates the client as needed and then generates a SAS. Once the client application receives the SAS, it can access storage account resources directly. Access permissions are defined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all data through the front-end proxy service.