Serverless Single-Page Applications with Auth0
I am excited about the idea of helping more people become web developers. One way I think that new developers will be able to start learning faster is if they don’t need to deal with servers. So, that’s why I’ve been following the growth of the “serverless architecture” concept lately.
I thought the term “serverless” had a faint smell of BS. I imagine cloud hosting salespeople trying to pry control out of the hands of the “real” developers. But here is the thing, when I am trying to quickly solve a problem, delivery value or build a lean MVP, I don’t want to have to know about any more layers of the system than I absolutely have to.
Data persistence
At the core of most user-facing web applications is reading and writing data to some persistent storage. You might be writing an MVC app and your controllers need to have access to a SQL database for reading and updating the models. Or possibly your are displaying a set of data fetched from an API, either your own or an external service providers.
If you don’t have a “server” to handle passing the right data to the browser and processing the user’s input through business logic.
Imagine you are just having the user’s browser query for data directly based on javascript code running on their computer. The biggest red flag with this idea is that you would have to give the browser some credentials to access the data. You can’t use your master API keys or username and password like you would in server-side code where it’s impossible for a user to see it. Instead you need to send a limited use authentication token that just gives that one browser access to only the records it should be able to access and only the permissions you want them to have (read, add, update, delete). But how do you get that token securely without hosting a server, and without exposing master credentials to the users?
Auth0 and Rules
Auth0 offers something that might help, they are a hosted user authentication service. They can keep a database of all your users for you, or integrate with other identity providers. So when you click “log in” your users are going to their servers and they are sending the user’s browser back to a specific page when they prove they are who they say they are. I have been trying out their email magic links and I think it’s really simple and nice for users to never create, save or remember a password. When a user enters their email address on the sign in form Auth0 immediately sends them an email with a unique token link, clicking that link proves identity and sends them back to my application. Since access to the user’s email inbox is, in reality, a skeleton key that unlocks every account anyway, I think email magic links are the best option.
So anyway, Auth0 has “rules” that you can run when a user successfully authenticates. This is the perfect place to run server-side code to get a one-time key.
For instance Azure Table Storage is a cheap persistence layer very similar to Amazon DynamoDB. I wanted to learn how to use some of these databases because they are an excellent option for a serverless app. With Azure Table Storage you can request a “Shared Access Signature”(SAS) which allows an end user application to work with a limited subset of data. I created a rule in Auth0 that uses my master key to request an SAS that allows full access to records whose “partitionKey” matches the current userId. This newly generated token is passed along to the web application url