How to talk to the Azure Storage APIs from a Single Page Webapplication (NuxtJS/VueJS) by using AAD (Oauth2 Implicit Flow)

Introduction

In today’s post we’ll go through how you can setup an SPA (Single Page Application) to access the data pane of an Azure Storage account. For this I’ll be using NuxtJS (a Vue.js framework) for my boiler plating, and will rely on the its generic Oauth2 authentication library. The awesomeness here is that the bearer tokens will automatically be injected in your API calls (Axios). Though you can use this post as inspiration on how to get things working in another framework too!

Why this post? It has has been on my personal todo list for a while due to many reasons. One of which is to remove the barrier of using Azure Storage in this scenario. I find that it makes a lot of sense in way too many use cases. Though I must admit we’ve failed to reduce the learning curve in this scenario! You suddenly find yourself in flux between the complexities of AAD and the way how Azure Storage handles the presented JWT tokens. That being said, this is actually the only correct (secure) way of talking from an SPA to Azure Storage. DO NOT use storage keys or SAS tokens in your SPA. It’s like leaving your master keys out on the porch of your house. AAD is the correct way, and actually… With an SPA, the only correct authentication flow is actually Implicit Flow.

 

Sample Code Repository

If you are looking for the sample code used for this post ; https://github.com/kvaes/TasmanianTraders-NuxtJS-AzureStorageExample

Call the Microsoft Graph API -and- your own API from a Single Page (JavaScript) Application

Introduction

If you have gone through the typical authentication scenarios, then you’ve probably seen that almost every single one is calling the Graph API. Where that is already cool as such, we’re all probably more interesting in using our own APIs… Today’s post will go through the process of calling -both- the Microsoft Graph API and your own API from the same code base.

 

Starting Knowledge Assumption

My assumption is that you are already familiar with the basics of Oauth, where you’re aware that a Single Page Application (SPA) is using an “Implicit Grant Flow“. Also be aware that the Azure Active Directory (AAD) v1 endpoint differs from the v2 endpoint in terms of resources & scopes.

In the v1 endpoint, you would target a “resource” in order to get authorization ;

Where the v2 endpoint rotates around the usage of scopes ;

The latter indicates both the resource & the permission that is targeted…

 

Setup of the day

As our test bed for today, we’re having a Single Page Application that has its own “Application ID” (clientid in Oauth). Which will be linked to two backend APIs; Microsoft’s Graph API and our own

Both our APIs have a given set of scopes that indicate the permissions that a user grants towards these APIs…

Using Azure DevOps to deploy your static webpage (SPA) to Azure Storage

Introduction

To, without shame, grab the introduction of the “Static website hosting in Azure Storage” page ;

 

Azure Storage now offers static website hosting, enabling you to deploy cost-effective and scalable modern web applications on Azure. On a static website, webpages contain static content and JavaScript or other client-side code. By contrast, dynamic websites depend on server-side code, and can be hosted using Azure Web Apps.

As deployments shift toward elastic, cost-effective models, the ability to deliver web content without the need for server management is critical. The introduction of static website hosting in Azure Storage makes this possible, enabling rich backend capabilities with serverless architectures leveraging Azure Functions and other PaaS services.

 

Which, to me, sounds great! As one of my projects (VMchooser) is actually a static site (VueJS based Single Page App) that could just as well run on Azure Storage (thus reducing my cost footprint). So today we’re going to test that one out, and afterwards integrate it into our existing CI/CD pipeline (powered by Azure DevOps).

 

When your Single Page App needs CORS and meets Azure API Management with a Function Backend

Introduction

When you have an SPA (Single Page App), all your code is being run inside of your browser. This means that, from a network perspective, you’ll be talking to the APIs directly. It’s often (rightfully) said that SPAs are an untrusted client, where a typical server-side app is seen as a trusted client. Why is an SPA seen as untrusted? Because from the publisher side (the one providing the service/app), you do not control the device running the code. So this has a huge effect on the security risks involved and how you should mitigate them.

 

One of those mitigations is “CORS” ;

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the first resource was served.[1] A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos.[2] Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy. (Source : Wikipedia)

 

With CORS, the request will indicate from which domain the calls would originate (and what actions / headers it would like to do). Therefore, the backend can check if the call is warranted or not…