In October 2024, we released AuthNxt—our next-generation authentication platform designed to integrate seamlessly with both our legacy TCL monolith and our modern microservices. This move was the product of months of planning, designing, building, testing, and integrating to ensure that all our services can identify FlightAware users and ensure account security across the stack. To date, our Go-based backend serves millions of requests per day, powering the flightaware.com website, our mobile apps, and countless microservices deployed in our datacenters.

If you’re curious about the engineering behind AuthNxt, check out our blog post about its development lifecycle and design trade-offs that went in to releasing this core service.

AuthNxt’s Infrastructure

At the core of our authentication service is a backend microservice written in Go. This backend manages all the logic for user authentication, including session management, JSON Web Token (JWT) generation, anonymous access for non-logged in users, and third-party sign-in support. In addition to the backend, we wrote a library for our modern Next.js applications and a compatibility layer in our TCL monolith for our legacy applications. Together, this provides seamless authentication across the entire flightaware.com domain via secure session and JWT browser cookies.

The Problem – GlobalBeacon Authentication

While our new authentication infrastructure has been considered a resounding success, it did not fully cover all our product needs. Namely, there was one major drawback to our existing architecture: it only provides sessions and JWTs to flightaware.com domains (things like www.flightaware.com, login.flightaware.com, etc.). This covers the majority of our services, but there is one critical service at FlightAware that was not covered by AuthNxt: GlobalBeacon.

GlobalBeacon was jointly developed by Aireon and FlightAware and is designed to be a first of its kind solution for ICAO’s Global Aeronautical Distress and Safety System (GADSS). This is a critical service for many FlightAware customers, providing real-time alerting and fleet monitoring on a global scale.

Much like our web monolith, GlobalBeacon is written in TCL and has its own bespoke authentication system. Furthermore, GlobalBeacon exists on a separate web domain: globalbeacon.aero. Thus, it cannot share its session cookies with our flightaware.com domains and cannot support AuthNxt’s session cookies. 

This presented a unique problem: we wanted GlobalBeacon to utilize the same authentication best-practices as AuthNxt, without weakening our session cookies to work across web domains. We originally considered building out a separate AuthNxt deployment specially designed for GlobalBeacon, but this came with several drawbacks—maintenance overhead, deployment headaches, compatibility, etc. We would much rather prefer a solution that integrates with the already-deployed AuthNxt service. 

Fortunately—as with many engineering problems—there’s a standard solving exactly that problem. 

Implementing OpenID Connect

OpenID Connect (OIDC) is an “interoperable authentication protocol based on the OAuth 2.0 framework.” It is designed to allow services (known as the Relying Party) to use a third-party provider (known as an OpenID Provider or Identity Provider) to verify a user’s identity using its own authentication and authorization framework. This offloads some of the heavy lifting of managing user credentials and identities onto a provider with a trusted authorization server.

We already use OIDC within AuthNxt. Have you ever signed in to an app using your Google or Apple account? If so, then you’ve already used OIDC! We support Google and Apple sign-in in AuthNxt. In this case, FlightAware acts as the relying party (RP), while Apple and Google act as OpenID Providers (OPs). In this case, we retrieve limited user information from Apple or Google’s servers and can associate the user’s email address with their FlightAware account. This offloads the authentication logic to these OP servers, which we trust to be secure from potential attackers. This is especially convenient on mobile devices, where Google and Apple sign-ins are well-integrated into Android and iOS, respectively.

From here, the solution seems simple: add functionality to AuthNxt to allow it to act as an OpenID Provider (OP) with GlobalBeacon acting as the relying party (RP) to verify user’s FlightAware account information. This would enable GlobalBeacon to utilize AuthNxt’s security and login flows while still issuing and managing its own sessions within the globalbeacon.aero domain.

Challenges

The single largest challenge with implementing OIDC is complexity. The OIDC specification is dense and has many requirements; it’s also based on the OAuth 2.0 Authorization Framework (RFC 6749), which itself has complex implementation considerations. To make integration as seamless as possible, reduce error rates, and provide a potential avenue to use AuthNxt for other non-flightaware.com applications, we wanted to adhere to these specs as closely as possible.

Fortunately, the fact that OIDC is a written specification means that the requirements are extremely clear; by adhering to the spec, we can utilize pre-written OIDC/OAuth 2.0 libraries to integrate with AuthNxt. There’s no need to write custom OIDC client code for every RP. To ensure that our implementation was correct, we created a small web app for testing OIDC implementations.

This app is simple: once registered as an RP, it can make authentication requests to AuthNxt. Upon successful sign-in, we are redirected back to the tester app, which shows the user information that has been returned from AuthNxt. This information is signed by the application and, thus, can be verified for integrity using AuthNxt’s public key. This proves that the user accessing the app is a real, valid FlightAware user.

In our OIDC tester, we simply display the response from AuthNxt to verify its contents. In a real-world application like GlobalBeacon, you would then need to issue a session for that user for use within your application. As part of this project, GlobalBeacon updated its authentication code for this exact purpose; it now provides its already-established session cookies but now backed by AuthNxt instead of its legacy authentication system. 

Impact and Next Steps

GlobalBeacon now has a modern, secure authentication solution that both provides security for our users and maintains parity with the legacy authentication solution. This allows users to sign in to GlobalBeacon with their FlightAware accounts seamlessly using the same login UI that AuthNxt implements natively. In fact, users already signed in to their FlightAware account don’t even need to sign in again! Simply authorize the integration and you will be signed in to GlobalBeacon automatically.

In the long-term, OIDC is an investment in our authentication infrastructure across the stack. In addition to securing the flightaware.com domain, we can also secure applications on other web domains using the same security best-practices. If we want to add another application as an OIDC client, we simply need to register it with AuthNxt and add an OIDC client library, and it will work out of the box.

Closing Thoughts

Authentication is a core service at FlightAware. That core was strengthened through the implementation of OIDC in AuthNxt, expanding its capabilities while simultaneously providing a solid authentication solution for GlobalBeacon.

Personally, this was a fantastic learning opportunity and a great way to deepen my knowledge on authentication and security best-practices. I am most excited to see how else AuthNxt will grow its capabilities in the future as we continuously adapt to changing security standards in the modern web world.