Shared access signatures (SAS)

- [Instructor] To adhere to the principle of minimum privilege, we will avoid using shared keys and rather use shared access signatures as a way of providing the specific limited privileges a client needs for accessing a resource within the Azure storage account. In particular, shared access signatures are used for blobs, files, and other mechanisms where we want to grant a specific permission to a client to take a very specific action. Looking in the Azure portal, select one of your storage accounts.

And below the Overview, below Access keys, is Shared access signature. Click on Shared access signature, and you'll see several of the options on the right-hand side. So shared access signature is essentially a unique token being generated for a client for a specific purpose. In particular, we an limit by service. So we can grant access to just one service, be it blob, file, queue, or table storage. We can limit the access by the type of resource, service, container, object itself, and of course, read, write, delete, these are all distinct permissions that we can select as appropriate for the client.

In addition, you can limit this by time. So if you're granting a client access to a particular resource, you may want to limit this by time and say that this token is now available to the client and they can conduct an upload or a download maybe in the next 10 hours. But then expire the token, so it does not live forever. You can also limit by client IP addresses, so you only allow access from certain locations. And the token itself will also specify whether HTTPs is required, whether both HTTP and HTTPS is allowed.

Do notice all the way at the bottom, this is dependent on the keys, so you actually use the keys from access keys, your route keys, that full access, to generate the SAS token. Let's click on Generate SAS. And when you scroll down, you can see an example. There is a SAS token. Starts with a question mark. Lots of interesting information. But also notice that there are URLs that encode the token. So if you look at the blob service URL. Doesn't matter what it says inside, at the moment.

But notice here that it says https, a domain name, forward slash, and then that is followed by the token. So we'll see that structure throughout our code examples, as well. So things to note. Your shared access signatures keys from before are essentially a route or administrator on your storage account. They can do anything. So whether they're disclosed inadvertently or whether assigned to a client specifically, they grant full access. SAS tokens is a better approach in that it allows us to provide minimum privilege to clients. So a client who needs to take a specific action gets only the privilege's permissions required for that action.

So whenever possible, use the SAS tokens instead of the shared access keys. The nice thing about SAS tokens are that they are, in fact, generated on the client. The server has no involvement here. The storage account actually does not participate in generating these SAS tokens at all, which means you can generate essentially an infinite number of these. Once the tokens are generated, the storage account's keys are not necessary on the client's side. And so you could store SAS tokens, you can exchange them, and you can essentially generate them on a privileged client, and then share them with the clients that needed the minimum privileges.

Bear in mind, though, that these SAS tokens are essentially secrets, so always use HTTPS. As you pass these tokens around, if you make an inappropriate copy of them, they could be misused. So now we have two ways to access storage accounts. We can authenticate using the access keys, essentially as a root or administrator user, or you could use a SAS token to authenticate and get authorization to use specific services in specific ways, and so do minimum privilege for clients that needed specific access.