Static website in Azure Blob Storage: How to enable Azure AD Authentication?

Question

I am hosting a static website through the $web container in the BLOB storage of an azure storage account. The minified JS in that container contains sensitive data, for example an azure-tables key.

According to the documentation:

You can modify the public access level of the $web container, but this has no impact on the primary static website endpoint because these files are served through anonymous access requests. That means public (read-only) access to all files.

Is there any way to limit access to the website's content (especially the minified JS sitting in the $web container)?

Anchoress

If you want to limit access to blob content, please keep your blobs in the static website as Private access and generate SAS token(learn.microsoft.com/en-us/azure/storage/common/…) for the blob you want to share. – Dottydoty

Does this limit access to the primary static website endpoint, too? – Anchoress

The endpoint like "contosoblobaccount.z22.web.core.windows.net/index.html" will be public but the endpoint "contosoblobaccount.blob.core.windows.net/$web/index.html" will be private – Dottydoty

Very interesting. Will try this out in the next few days. – Anchoress

The minified JS in that container contains sensitive data, for example an azure-tables key. - It's really a VERY BAD IDEA to keep the keys (assuming you're talking about storage keys) in a JS file. – Fort

@GauravMantri if access to the entire website's content is locked behind AD authentication and no data validation is necessary for this small webapp that will only be accessible for about 90 known people, how is that bad? – Anchoress

This app is a prototype to collect experience about azure-tables and how it works from the browser and with redux-saga-requests. It's not a production app. If this method of authentication doesn't work out or we do in fact need server-side validation, we'll look at options for a back-end. But for now, we don't need a back-end. – Anchoress

Imagine one of those 90 people share your account key (either accidentally or intentionally) to the whole world. Having access to storage key essentially makes a person owner of that storage account and that person can do a lot of bad things. – Fort

If it is not a production app, you can host it for free in Azure WebApps. You will get all the benefits of server-side code in this case. – Fort

Thank you for the suggestion! Many of my coworkers are backend devs, so I'll bring it up on Monday and we'll see where we go from there. – Anchoress

@Anchoress If your issue has been resolved, please add the answer to the answer part. Then this issue can be closed. Thank you. – Johannessen

Thanks for the reminder, I'll get right on that today. – Anchoress

That was odd. Felt like talking to myself. – Anchoress

Answer 1

First of all, it is very bad practice to store data access tokens in the website's code, no matter how minified the JS is. The access tokens could be leaked by anyone who has read access to the website, intentionally or unintentionally. That includes being able to open and view the site in their browser.

If you're already thinking about authentication, an Azure Blob Storage service isn't going to cut it. You're probably going to need a free Azure Web App or two (One for the frontend, one for the backend). Server-Side code is much safer than browser code and enables features like proper user input validation. Additionally, enabling Azure AD Authentication is just a click away if you're using Azure Web Apps.

It is possible to generate SAS tokens that require the user to authenticate via Azure AD before accessing the Blob, but I personally haven't tried that yet.

Anchoress