Understanding the structure of the NASS - Naflows/naflows-auth GitHub Wiki

Naflows Logo

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.