Taking the user delegation SAS tokens for a spin


A few days ago the preview for the “User delegation SAS token” has seen the light. In today’s post, we’ll take a first glance on this new capability! Though why should we care about this feature? You can now create SAS tokens based on the scoped permissions of an AAD user, instead of linked towards the storage account key. From a security perspective this is REALLY awesome, cause you can harden the scope of a possible even more.



Azure RBAC

When going through the RBAC roles, you can see a new role in there ;


Though this role is also included in the other roles too ; https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#storage-blob-data-reader 

So why does it exist? You need to have the delegator rights on account level. So if you want to be very specific… Granting someone this role on account level, and giving them permissions on container level will be more granular / scoped. Though in this case you need both.


Azure CLI

Check the help pages on “az storage blob generate-sas” ;

For me the most funky parameter was “–expiry”, though the help file provides some good guidance here!


Error : Older Azure CLI Version

If you see the error “az: error: unrecognized arguments: –as-user”, then this is because the version is out of date

Install the new CLI ;

And then it’ll work.


Testing the flow

So we have a little test environment ;

Let’s test it without a SAS token…

Pfew, that doesn’t work (as designed!). Now, we’ll generate the SAS token,

az login

az storage blob generate-sas –help

end=`date -d “30 minutes” ‘+%Y-%m-%dT%H:%MZ’`

az storage container generate-sas \
–account-name kvaestest001 \
–name test \
–permissions acdlrw \
–expiry $end \
–auth-mode login \

And add it to our blob URI ;

Boom it works!


What about B2B users?

I’ve added my @kvaes.be (owner) and my @microsoft.com account to this. The @microsoft.com account is a B2B user in this case.

Let’s log in with that account and generate a SAS token


And test it…

B2B users work! 😉


Error Handling : Date in the past

If you see a funky error mentioning some XML stuff… Then it’s probably due to the fact that you didn’t format the datetime of the expiry correctly.


Error Handling : AAD user has no access to data

If you have no access to the data, you will be able to get a token. Though it won’t work once you’re trying to use it!

The easiest way to test this, is to browse to the storage account and change the “Authentication method” to “Azure AD User Account”.

And ensure that this isn’t set to “Access key”.

If it works via the “Azure AD User Account”, then you know this user has the rights to the file.


Revoking Access

What about revoking SAS tokens?

There you go… A bit blunt at the moment, but it does the trick! 😉


Closing Thoughts

The user delegation for SAS tokens is an awesome step in the security of storage accounts. It relieves you from needing a storage key. As you can see in our tests, you can go more granular in terms of permissions and it also works for B2B users. Whilst still in preview, I’m excited to see this one see the light of day!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.