Lambdas are a great addition to the tech ecosystem by Amazon. They can help bootstrap projects and fulfill a wide range of specific use cases. Given their usefulness, at some point, you may want to add authentication capabilities.
When using AWS Lambdas, you can use the API Gateway to handle authentication and it works just fine. The only pain point is how annoying it is to correctly set everything up and have a good dev experience.
Given the annoyance involved, I prefer going with Netlify or Zeit for personal projects. I find their abstraction of Lambdas much simpler and faster to setup without the API Gateway.
In this article, we will see together how I came to use function wrappers to help me handle authenticated routes on Lambdas in a maintainable and easily reusable way.
Note: We all know the server side authentication topic is super wide, so this article will only focus on JWT authentication.
Authentication with Lambdas
To set the stage, let’s start with what I was doing in the first place that led to this search. I was trying to accomplish a particular issue: how do I make Lambdas that will run only for authenticated users, or admins specifically? After some research and experimentation I found a few potential options.
Here are the options I discovered, and their pros and cons.
Since we are looking at Node.js Lambdas, we are able to reuse production-ready user authentication frameworks. A well known one would be Passport with Express. If you are used to Passport already or if you are looking to handle multiple login providers by yourself, then using Express can be a good choice.
Good resources have already been created regarding this topic if you’re interested in going down this path. Here are some:
However, I felt that it was a bit off to set up an Express framework when using Lambdas, as if it were defeating the purpose of Lambdas: small bits of codes with only the minimum required. Additionally, since I only want to verify a JWT token, I didn’t feel the need for everything that comes with Passport.
Using inline checks
The next option I considered was using inline checks. Here is a simple example of how to perform inline checks:
On the plus side, this method is simple and easy to understand. However what bothered me was:
- This method mixes authentication code and operational code.
- You do not completely abstract away the authentication code, making it annoying to reuse. If I had to protect another route, I would have to reimplement the same unauthenticated response logic.
Those downsides were too much for me. I quickly dismissed it and searched for another method.
Working with React at Sqreen for a few years now made me think of one way to abstract logic in React: function wrappers. As such, I tried to implement a simple function wrapper to help me handle authentication and see where it could lead me.
Here is my Lambda code
And here is my wrapper code:
Now we’re talking. This method was the best one that I found. Using a wrapper is as explicit as the inline checks method and it’s easier to split concerns.
You do not mix authentication code with operational code, and you can focus on what your function should do.
The best part is that it’s easily reusable, can be extended to handle additional login types, and can even be combined with other wrappers.
You can checkout this code repo if you want to run some code to experiment with function wrappers yourself:
I hope that this article gave you some fun ideas for your next project!
If this piques your curiosity, you can also have a look at
compose() that would allow you to easily chain wrappers. Check out this article for more info:
Note: When working on this article I stumbled upon https://github.com/middyjs/middy, a pretty cool middleware engine that also helps you do the job. Worth a look!