Legal Document Management Solution

Leobit engineers built the desktop client on .NET MAUI, Microsoft’s framework for native applications running on .NET. Since the customer’s back end was already built on .NET, this choice kept the entire solution within one technology ecosystem, so the desktop application could reuse existing logic, tooling, and engineering expertise instead of introducing a separate desktop stack.

For the user interface, the team used Blazor Hybrid as a container. In this setup, the interface runs as Blazor components inside the native application, allowing the team to carry over the structure and workflows of the existing React front end rather than redesigning the product from scratch. Users work with the same screens they know from the web version, now running as a native application with direct access to local resources on the machine, including the local database and cache.

This project required Windows support only. All users are internal employees working on Windows machines, so there was no immediate business need for additional operating systems. The technology itself is cross-platform, and the team designed the architecture with that in mind: if the customer decides to expand later, the same application can be built and run on macOS without a rewrite.

When every component lives in the same Azure environment, related resources sit in one resource group and communicate freely because Azure recognizes them as part of the same infrastructure. Introducing external access from a desktop application breaks that assumption. Every remaining connection between the desktop client and cloud services had to be secured individually.

The team evaluated two options. The first was to configure an individual API key or certificate for each connection, so each cloud service authenticates the desktop client independently. The second was a single identity layer between the desktop application and the remaining cloud services: the client authenticates once, and the identity service determines whether it is authorized before granting access to the appropriate services. On Azure, this maps naturally to Microsoft Entra ID.

The desktop application authenticates users through Microsoft Entra ID and receives short-lived access tokens that are used to call authorized APIs, while token renewal allows users to remain signed in without repeatedly entering their credentials. Azure centrally manages access policies and permissions, so individual cloud services don’t need to maintain their own desktop-client credentials.

This also simplifies credential rotation and revocation: access can be changed centrally without redistributing API keys or certificates to every installed application. Where certificates or application credentials are required for service-to-service communication, they can be managed and rotated centrally rather than embedded in the desktop client.

Many cloud services charge based partly on request volume, computing resources consumed, and operation complexity. With the desktop architecture, the application performs most operations against its local database and synchronizes with the cloud periodically. Instead of hundreds of individual cloud requests, the system runs one periodic sync, which sharply reduces SELECT operations and other queries against the cloud database.

The bigger opportunity is in shifting processing away from the cloud. Previously, a user retrieved a document from the cloud, and every subsequent operation ran through cloud-hosted APIs and back-end services. Now the document can still be retrieved from the cloud when necessary, but subsequent operations run locally on the user’s machine. The cloud remains responsible for what genuinely requires centralized access: shared data, synchronization, collaboration, and APIs.