Flipping the script: McDonald’s modular auth architecture journey

McDonald’s evolution to a modular auth architecture is optimizing and centralizing our approach to authentication and authorization.

by Shital Sonavane, Software Engineer III

In today’s interconnected digital landscape, security stands as a paramount concern for software developers and system architects, alike. With the proliferation of user interfaces (UIs) and the adoption of microservice architectures, ensuring robust authentication and authorization mechanisms has become critical.

Authentication verifies the identity of users or services attempting to access a system. It ensures that only legitimate users gain entry, safeguarding against unauthorized access and potential security breaches.

Authorization, on the other hand, determines the permissions and privileges granted to authenticated users or services. It governs what actions users are allowed to perform within the system, enforcing access control policies and protecting sensitive resources from unauthorized use or modification.

In this blog post, we’ll dive into how McDonald’s empowers secure communication among its internal microservices and micro-front-end applications through a centralized, custom authentication-and-authorization model as part of its transformation journey.

Monolith application architecture
Within the current monolithic application architecture, user permissions are associated with a database field, and authentication and authorization are tightly intertwined within the same application, intermixing functional and security aspects.

In this setup, changes to user permissions are made directly within the application code, potentially leading to code complexity and maintenance difficulty.

Additionally, this tight coupling between authentication, authorization, and the application logic can hinder scalability and flexibility, which can make adapting to changing business requirements or integrating with new authentication systems challenging.

Moreover, the lack of separation between these concerns could pose security risks, as any vulnerabilities in the authentication or authorization mechanisms can directly impact the application’s functionality and data integrity.

In our new system, our goal is to deconstruct the monolithic application into several subdomains, each equipped with its own UI (micro-front end), API (microservice), and data source. Nevertheless, we aim to establish a centralized authentication and authorization model across all these subdomains to ensure a unified security approach.

UI (micro-front end) auth architecture
Micro-front end is an architectural style that applies the principles of microservices to front-end development to address the challenges of developing large, complex front-end applications. In a micro-front-end architecture, a front-end application is broken down into smaller, more manageable pieces, each of which is developed, deployed, and maintained independently.

Our identity provider offers the option to allow SAML integration, enabling logins from external and corporate identity providers. In this scenario, we leverage a global authentication service to access these independently hosted micro-front-end applications.

To handle authorization, we built a user-info microservice to provide detailed permissions. After the user is authenticated via the login screen and obtains the OAuth 2.0 token, the UI application will use this access token to invoke the user-info microservice. It fetches the user’s specific permissions and restaurant operational group details, which the UI apps use to manage the UI view.

Microservice auth architecture
Microservice architecture is a design approach used in software development, where a large application is composed of loosely coupled, independently deployable services. These services are organized around specific business functionalities and communicate with each other through well-defined Application Programming Interfaces (APIs).

As we transition from a monolithic architecture to microservices, following the MACH approach, our focus is on decoupling and modernizing our system. One critical aspect of this transformation is the assignment of permissions to our headless APIs. These APIs, now separated from the monolith, serve as the primary interface for our application functionalities.

Due to the necessity of simultaneously supporting both architectures for a transitional period, a challenge in this new architecture emerged: effectively managing fine-grained permissions within each microservice, inherited from the monolithic architecture. To address this issue, we built the user-info microservice, which augments the user-info endpoint and provides details around the custom scopes by connecting to monolith system. Auth microservice can use this response to authorize the requests.

Components involved
API Gateway: The API Gateway serves as the primary entry point for inbound requests directed toward any microservice within the system. Within the context of AWS API Gateway, we harness its capabilities to establish authorizers, integrating them with every API endpoint. Upon receiving each request, the API Gateway routes it to the designated authorizer (our authentication microservice) to validate the access token.
Contingent upon the authorizer’s response, the API Gateway orchestrates the onward journey of the request, either directing it toward the respective microservice pods or dispatching the response back to the requesting consumers.

Furthermore, we have the capability to manipulate the request and response entities, facilitating dynamic customization of the data flow. This incorporates user claims into the request header, enabling validation at the API level. This functionality assumes paramount significance in the context of API-to-API communication within our service mesh architecture, fortifying the integrity and security of our inter-service interactions.

Auth microservice: The auth microservice enables fluid and cohesive communication between upstream microservices and an array of authentication components. Its functionalities are tailored to meet the intricate demands of modern authentication processes, encompassing:

1. Validates signature: The microservice delves into the OAuth signature validation, navigating through the cryptographic complexities inherent in each incoming request. Signature validation, establishes an initial line of defense, helping to strengthen the integrity and authenticity of interactions within our system. Through its examination, the auth microservice establishes a foundation upon which trust and reliability flourish, shielding our ecosystem from unauthorized access attempts and potential intrusions.

2. Validates scope: Beyond its role in signature validation, the auth microservice encompasses endpoint-scope validation, sourced from a centralized database that houses endpoint mappings with scopes. It evaluates the appropriateness of each requested endpoint within the broader context of user permissions and access privileges. By harmonizing user entitlements with endpoint scopes, the auth microservice orchestrates alignment between user interactions and system functionalities, helping to ensure adherence to our security protocols.

3. Fetches users’ fine-grained permissions: Central to its mission of comprehensive user validation, the auth microservice integrates with our monolithic application, extracting fine-grained user permissions. This synergy enables the auth microservice to tap into the reservoir of user-centric data, housed within the monolith, acquiring insights into each users’ entitlements and restrictions. By harnessing this granular level of detail, the auth microservice enriches its validation process, scrutinizing user interactions against the backdrop of their individual permissions.

4. Validates users’ fine-grained permissions for the requested endpoint: With the repository of fine-grained user permissions from the monolithic application, the auth microservice validates each user’s entitlements against the specific endpoint being accessed. This helps enforce adherence to predefined access-control policies and mitigate the risk of unauthorized access and interactions.

The auth microservice’s multifaceted functionalities serve as the linchpin of our security infrastructure. It helps empower our organization to navigate the intricate terrain of user validation with confidence and assurance, safeguarding the integrity and trustworthiness of our software ecosystem.

User-info service: User-info micro service pulls the user’s fine-grained permissions from the existing monolith application. It accepts user identifier and returns the user permissions in response.

Conclusion
While our journey toward MACH architecture may entail obstacles, the potential benefits can make it a worthwhile endeavor.

McDonald’s showcases how segregating user authentication and authorization functionalities into distinct systems within a microservices architecture not only addresses the limitations of monolithic architecture, but also fosters independent development, deployment, and maintenance.

Moreover, the adoption of micro-front-end applications within the MACH framework necessitates a centralized approach to authentication, ensuring secure communication channels and streamlined access control across diverse front-end applications and microservices.

Within the MACH architecture, the retrieval of user permissions through a common microservice streamlines access control and enhances security across diverse microservices and front-end applications. This simplifies the management of user permissions and ensures consistency and reliability in enforcing security policies.

With the proper planning, execution, and continual upkeep, this approach can enhance flexibility, scalability, and security. Organizations can navigate this transition with advanced DevOps methodologies and a commitment to security and collaboration, ultimately paving the way for a more efficient and secure digital infrastructure.