Building a QR Code Auth System.
A few weeks ago, @AppAirport for iOS was released. We wanted to create a similar experience for all our users particulary those on the Web, as well as those who didn't have iOS 14. Given TestFlights limit of 10K downloads, we wanted to make sure that we were able to get a web version out, and out soon, since it was evident there would be a demand for it.
To create a smooth Web experience, we wanted to roll it out to our already growing list of users who had the mobile app first. This would allow us to scale our brand spanking new infrastructure, in a way that would inform us if we were ready for the traffic that @AppAirport mobile app is generating. The Web App itself is a React Application, but one flow @Jordan and I had fun with, was the idea of scanning your boarding pass to get in.
While this seems pretty trivial at first, it's not that simple. Apps like WhatsApp can use this because they're already tied to a user. We don't support any users per se, yet, so it was a different challenge we ended up having to navigate. We needed a way to create a unique user and keep them logged in, every time they logged in from their device. The only way a user can log in is if they scan the boarding pass, through the Airport App, or if they enter a code (Code drops coming soon, as we look to open the doors on our Web App).
How we did it?
Each web session is essentially a unique entity for us, we are generating a random QR code on each user's first-page load. Once we generate a UUID, we're saving this to the Local-Storage (if you clear your cache you'll have to re-authenticate). This is the only way we were able to guarantee such a system, without building a robust user authentication system throughout the app.
The Web Side.
Once this UUID is stored, we essentially are using a Web-Socket based approach where we connect the user to our Web-Socket server and listen for any changes on the server. The only way a change can happen on a server is a) if the user scans the boarding pass or b) if the user enters the correct access code. If either of those is true we flip our Web-Socket value to true for the UUID, save the UUID, and allow the user access to Airport. The access-code is also wired to the WebSocket server, so we can change it server-side, and it'll update instantly.
The iOS Side.
@Jordan also had to make sure our iOS QR reader was finely tuned to handle this situation. The QR code you see on Airport is not just a simple UUID, it's prefixed with some unique text that our iOS QR reader looks for. If it finds the prefixed code, it goes ahead and updates our Web-Socket API, and flips access for that unique user to true. The Web-Socket API value is read by the client, and that user is instantly allowed access. This whole flow takes less than 35ms of time, which is something we're truly proud of. Based on our current calculations, we should be able to handle upwards of 200K concurrent logins at this time.
Some Learnings.
Being able to develop Airport in one week (Web and iOS) has been a challenge, but it's an extremely welcomed challenge, because of the amount of support we're receiving from the community. We can't wait to form this into a growing platform, and we have so many new things planned to keep our Airport running. We can't wait to fully open our doors on the Web, so everyone on our waitlist can have a similar experience to our users on iOS. Thanks again for the sheer volume support we've seen on Airport, we're all Developers/Creators/Innovators here, let's build something great together! Follow @AppAirport on Twitter (We'll be dropping some Web Codes real soon!)