Understanding the structure of the NASS - Naflows/naflows-auth GitHub Wiki
About
This section is designed to give you a detailed understanding of the NASS structure. Grasping how it works will help you appreciate the level of security, robustness, and reliability we aim to build into the NAFLOWS infrastructure.
By going through this complete guide, you'll be better equipped to contribute effectively to the backend and help us continuously improve it.
Basic overview
The core of the infrastructure is the NASS, which serves as the mediator of the entire request/response system. Acting as a shield, it blocks insecure or potentially harmful actions before they reach the inner layers of the system.
While each backend in the Naflows ecosystem is individually secured, they do not expose access to sensitive data such as user information, tokens, or sessions. Instead, they function as bridges—interfaces designed to allow users to interact with the Naflows system in a strictly controlled manner.
The key principle behind this architecture is restricting interactions to predefined, explicitly coded requests. This means that only known and authorized routes can be triggered. As a result, the surface area for attacks is significantly reduced, and focus is placed on maintaining and securing a finite set of trusted entry points.
Going deeper into the structure
About the requests
Naflows' system is built around a specific request structure: the User-Client Request format (called UCR
).
UCRs are a simple way of controling incoming data's structure to fit the system's process. This UCR is only built in the incoming requests, for the corresponding API only sends particular informations about itself, the actions is has done and its details, and the result code, status, and message.