My Lambda Labs Experience
Introducing Scribble Stadium, a creativity fueled battle-royale
For the past 6 weeks, my team of frontend/backend/UX engineers have been working on Scribble Stadium, a web application targeted to grade school children designed to optimize screen time by unleashing creativity through reading, writing, and drawing. Created by Graig Peterson (6th Grade Educator) and Darwin Johnson (Data Scientist), this is an application designed to compete with other so-called “mindless” alternatives such as Fortnite and “turn reluctant readers into authors and illustrators”. This was certainly no easy task, with Fortnite alone racking in more than 15 million concurrent players, how does one take a piece of that proverbial pie? Well, you turn it into a weekly competition where kids battle it out with their peers and the Scribble Stadium community votes on their favorite user submitted stories and illustrations. The player with the most points at the end of the week takes home the virtual crown and some well-deserved bragging rights! 👑
The Task: Beefed up Security
I was tasked with working on the user-facing components on the frontend and responsible for implementing a user friendly authentication system. If you are unfamiliar with Authentication, it’s essentially a means for the application to allow users to login by comparing their username and password to what is stored on the database. The API will then send back what is called a JWT (or “jot”), an encoded JavaScript object that can contain a variety of information including identification information about the user, timestamps, encryption algorithms, expiration dates, and so on. We can then use that JWT and pass it back and forth between the front and backend whenever the user wants to access features that require authorization. Think of Authentication as the bouncer at a nightclub that checks your ID before letting you inside the establishment.
The Challenge: Out with the old, in with the new
There was already an authentication system in place called Okta, however, it was unreliable and not living up to the standards set forth by the stakeholders. It was determined that a new platform called Auth0 would be an ideal replacement given it’s reliability, simplicity to setup, greater security features, and favorable reputation in the development community. The team and I were thrilled to be working on this feature since it was a technology we were unfamiliar with and would allow us to master a new tool that we could use beyond our labs experience.
We quickly got to work and created new accounts on Auth0.com so we could peruse through the official documentation and figure out how to implement this in the current Scribble Stadium codebase. One thing that was immediately clear was that the Auth0 documentation was super user friendly! They provide you with step-by-step “quick start” guides and sample projects for every framework you can think of. They even provide you with detailed sample code that you can duplicate to get up and running in minutes. The first step was to install all of the necessary dependencies using NPM or Yarn and wrap the App component on the index.js file with Auth0Provider to provide global access to all of the built-in Auth0 functionality throughout the project.
Wait a minute…
Starting any new project requires a certain level of preparation or planning, but working with an existing codebase can be even more challenging and present you with some unique obstacles. As I mentioned earlier, there was already a system in place called Okta, so it wouldn’t be as simple as dropping in the new Auth0 code and calling it a day (although we secretly hoped that we be the case). The team and I had to figure out what components were previously using Okta, and come up with a solution to replace that logic using Auth0.
We determined that there were 50 components on the frontend that were reliant on Okta with corresponding test files for each component, in addition to a middleware component using the Okta logic on the backend. Wowzah! Suddenly our dreams of a quick and painless swap became a distant memory, and we realized we had our work cut out for us to meet our Sprint deadline. I was fortunate enough to work with a group of determined hard-working engineers so we all graciously accepted the challenge and came up with a game plan. Since I was the only frontend engineer, my Technical Project Manager and UX engineer volunteered to tackle the workload with me (teamwork baby!). We would split up and each work on one-third of the components and simultaneously submit Pull Requests after all of the work had been completed.
I first began working on the Login page, which seemed like a logical place to start and it’s one of the first components that’s demonstrated in the Auth0 quick start guide. The existing Login page was pretty straight-forward, the previous team created a functional component called LoginContainer that returned an embedded login widget that’s provided by Okta.
Here’s when things became a little tricky. Auth0 doesn’t have an embedded widget like Okta, and in fact, they recommend not using any type of embedded login form due to possible compromises in security. Auth0 uses what is called a “Universal Login Page”, where the user is directed to a secure external site to perform their login, and then they’re re-directed back to the original web application after their information is validated. The procedure executes pretty seamlessly and you’re even able to customize the theme and styling of the Universal Login Form with your own images and colors to match the style of your application.
Time to get to work!
I made the decision to remove all of the existing code on the LoginContainer component and simply add a button on the homepage that the user would click on to be directed the Universal Login Page and complete their login. This would significantly reduce the amount of code needed to perform the original task. Auth0 provided some awesome sample code for this exact task; they give you access to a built in hook called loginWithRedirect that you pass into the onClick function of your button element that takes care of directing the user to the Universal Login Page as well as redirecting back to the original application after validation.
Sign-in Successful
The login button was now in place and things were certainly looking up! The styling was not exactly how we envisioned but we were focused on functionality first and styling at a later point. One important step to remember here is that you must make sure that your Allowed Callback URL’s, Allowed Logout URL’s, Allowed Web Origins, and Allowed Origins (CORS) values are all setup on the Auth0 dashboard for everything to function properly. This project was running on http://localhost:3000 so I used that same URL on all of those respective fields. You will have to update these values again once you eventually deploy your project but there is plenty of documentation on the site that covers that if needed.
We Push Forward
With the Login component out of the way, it was time to focus on the other 49 components that needed to be swapped over to Auth0. A common theme with the other components is that they were all using similar logic so if we were able to figure out how to fix one component, we could then model that logic for the others.
Here’s an example of how each one of the components were structured. They were using built-in Okta logic to obtain the users authentication boolean value (either true or false) using “authState” as well as the user’s personal identifying information such as their name, email address, and avatar image using “authService”. That information was then being cached, or stored in state, and passed along as props to other components that relied on that information. We needed to find an alternative method to perform the same task with Auth0.
We discovered that Auth0 had similar built in logic that we could use to replicate what was done by the previous cohorts. Auth0 gives us access to some built in hooks: “user” to obtain the user’s information, “isAuthenticated” to determine if they were logged in or not, and “getIdTokenClaims” to retrieve the user id_Token. The team and I then brainstormed and created some logic to store the id_Token to localstorage and the users personal credentials to application state so we could easily pull that data whenever we needed it. We would replicate this structure on all of the other components as well.
Why store the id_Token?
While the three of us were working on the frontend components, our backend engineer was also working diligently on the backend API. There was a middleware component on the backend that was also using the Okta service, so it was important to swap that over to Auth0 as well. The middleware was designed to ensure the user was Authenticated whenever we made an API request from the frontend (such as obtaining profile data, leaderboard stats, adding players to the child’s team, etc.). In order for that request to be successful, the API needed to verify and decode the user’s id_Token. There was an existing function on that frontend called getAuthHeader that handled this request in the past, but as you may have guessed, it was designed for Okta. The function essentially used built in Okta logic to determine if the user was authenticated and returned Authorization Headers containing a “Bearer idToken” that was passed on each CRUD request.
This is where the data that we stored to localstorage earlier becomes super helpful! We were able to modify the getAuthHeader function and pull that information directly into the getAuthHeader function using good ol’ Javascript and calling localstorage.getItem. The logic would remain intact and we were able to send that critical id_Token over to the backend API by passing getAuthHeader as a parameter on each CRUD request🍻
Testing, testing…
With a handful of components swapped over to Auth0, it was time to perform some important (and often forgotten) tests to ensure that our application was performing how we expected it. If you’ve ever worked with existing code bases in the past, then you’ll know that even minor modifications to one component can alter the behavior of your other components or break the application altogether. It’s like fixing your car’s brakes, and the muffler suddenly falling off..oof!
For Scribble Stadium, we were using Jest, a testing framework created by Facebook, that allows you to perform Unit Tests directly in your IDE’s terminal. I had experience using Jest on previous Lambda projects, so I was familiar with how to set it up and get everything up a running. I ran an initial test on the NewParentDashboardContainer file I recently swapped over to Auth0, and sure enough the test suite returned that infamous red result of doom.
Failure is not an option..
Looking at the test file itself, it became immediately clear what the issue was and what I needed to do to rectify the situation. The tests were setup to “mock”, or use dummy data, on the authentication logic for Okta. Since that component was no longer reliant on Okta, all I needed to do was replace the mock parameter with Auth0, since that was the service we were using moving forward.
I didn’t find a lot of documentation regarding testing on the Auth0 website so I did have to utilize additional resources to come up with a solution. It’s key to remember, if you’re ever having an issue, chances are another developer most likely had the same issue too. The development community is always super helpful and willing to share best practices if you need it!
That’s more like it! Each component that was modified using Okta needed a similar fix to the corresponding testing file as well. It can be a lot of tedious work, but testing is an essential part of the development process.
In conclusion
I really enjoyed learning how to incorporate Auth0 on this project, it truly opened my eyes to the future of application security and the endless possibilities of “cloud-based services”. As more and more companies begin to inevitably push the boundaries of technology, it’s companies like Auth0 that will stand at the pearly gates and welcome these companies with open arms. Only time will tell if these types of services can withstand the barrage of imminent cyber “jerks” but for now, this is the gold standard for me and what I’ll be using for authentication on future projects. I’m truly grateful for my Lambda Labs experience and can’t wait to start a long and rewarding career in tech.
Shout-out to Team C for all of their hard work and countless hours of dedication, and thank you to Scribble Stadium as well for giving me the opportunity to work on this awesome product. Cheers!