Data Alchemy delegates identity to LoginMaster
Data Alchemy turns business documents into structured data with AI. On authentication it made a deliberate choice: not to build it. Every login, every role and every second factor goes through LoginMaster, while the product team stays focused on data extraction.
The challenge: a document SaaS cannot improvise identity
Data Alchemy is an Intelligent Document Processing platform: it ingests invoices, delivery notes and orders, extracts their data with AI engines and pushes it into ERP systems such as SAP, Zucchetti and TeamSystem. That means it handles a company's most sensitive documents every day — the ones accounting and the supply chain are built on.
A product like this immediately faces three requests that arrive together with the first enterprise customer. First: "my employees must sign in with their corporate credentials", meaning Microsoft Entra ID or Google Workspace. Second: "my freight forwarder and my accountant need access too, but they don't have a licence in my Microsoft tenant". Third, and most treacherous: "one customer's data must never be able to surface in another customer's view".
Answering that by building authentication in-house looks like a few weeks of work. It isn't. It means owning, forever, password management, secure resets, second factors, brute-force protection, token lifecycle and revocation, provisioning and deprovisioning, access auditing. It is a product inside the product: every month of development spent there is a month not spent on document extraction accuracy, which is the only thing customers actually pay Data Alchemy for.
The solution: the application does not implement authentication
Data Alchemy chose to delegate the entire identity domain to LoginMaster. The application does not verify credentials, does not store passwords and does not manage second factors: when a user signs in, the platform calls its own LoginMaster project and receives a signed token, which it verifies against a dedicated public key.
The architectural point is this: Microsoft Entra ID, Google Workspace and local accounts coexist without Data Alchemy writing a single line of code for any of them. Federation happens inside LoginMaster and stays transparent to the application. If a customer asks for a new provider tomorrow, there is no Data Alchemy release to ship — there is a tenant configuration to change.
The same holds for external users. A consultant, a supplier or an auditor gets a LoginMaster account and signs in without consuming one of the customer's Microsoft or Google licences, and without their credentials being handed to a third-party service: they stay inside the customer's LoginMaster tenant. Users set their own password and enable their own second factor, with no temporary passwords travelling by email.
How the integration works
Four architectural properties that explain why the integration scales with the product instead of having to be rewritten.
- 1
Identity lives outside the application
Data Alchemy does not implement credential verification: it delegates to its LoginMaster project and gets back a signed token, verified against a public key dedicated to that project. The attack surface tied to passwords simply does not exist in the application's code.
- 2
Corporate providers are configuration, not a release
Signing in with Microsoft Entra ID, with Google Workspace or with local LoginMaster accounts is the same thing as far as the application is concerned, because brokering happens inside LoginMaster. For customers running on-premise Active Directory, the access mode is governed centrally on the LoginMaster project side.
- 3
Roles come from the token
Data Alchemy's authorisation builds on the role carried by the token — administrator, tenant administrator, manager, user, technician, application account — and derives its access control from it. Changing someone's role is a console operation, not a change to the application database.
- 4
Per-tenant isolation, data where the customers are
Every customer has a dedicated tenant and isolated data. The LoginMaster tenant can live in the customer's own datacentre: user credentials are entrusted neither to Data Alchemy nor to a third-party cloud service.
The product that came out of it undistracted
Having never had to build an authentication system, the Data Alchemy team invested its time where customers measure it: the quality of document extraction.
99.8%
accuracy in data extraction
~3 sec
per processed document
−60%
operational time on document workflows
0
lines of authentication code to maintain
Data source: The first three metrics are stated by Data Alchemy on its official website and refer to the performance of its Intelligent Document Processing platform, not to LoginMaster. The last one describes the architectural choice this case study is about.
Technical perspective
For the IT department
No authentication system to maintain
Password resets, brute-force protection, token rotation and revocation, second factors: all of it is LoginMaster's responsibility. Nobody gets paged at night over a login incident.
External user onboarding without tickets
The user is invited by email, sets their own password and enables their own 2FA. No temporary password to communicate, no manual help-desk step.
A single point of revocation
When someone leaves the company or a supplier's contract ends, access is removed from the tenant console and applies across the platform. No chasing accounts application by application.
Centralised access auditing
Who signed in, when, and with which role is a question the identity provider answers, with technical evidence that holds up in a GDPR or NIS2 review.
Business perspective
For the CIO
Licences no longer follow external users
Consultants, suppliers and auditors sign in with LoginMaster accounts. There is no need to buy each of them a Microsoft 365 or Google Workspace licence just to let them into an application: the cost per external user decouples from the cost of the corporate suite.
Time to market doesn't pay the authentication toll
Building identity in-house is a construction site that never closes. Delegating it keeps the development budget on the product's differentiating value — which, for Data Alchemy, is how precisely it reads a document.
Data sovereignty, not just paper compliance
The tenant can sit in the customer's datacentre, in Europe. Credentials never cross non-EU providers, and the answer to compliance questionnaires becomes an architectural fact rather than a contractual promise.
One identity provider, many applications
The same identity provider that authenticates Data Alchemy can authenticate the rest of the portfolio. SSO stops being a per-application project and becomes a shared service.
Frequently asked questions about this case study
No. The application does not implement credential verification: it delegates to its LoginMaster project and works with signed tokens that it verifies against a dedicated public key. Credential management stays inside the LoginMaster tenant.
They get a local LoginMaster account. They are invited by email, set their own password and enable their second factor. To the application they are users like any other, because the provider type is transparent: only where LoginMaster verifies the identity changes.
No. Brokering to Microsoft Entra ID, Google Workspace or local accounts happens inside LoginMaster. The application always receives the same signed token, so adding or switching providers is a tenant configuration, not a software release.
The user's role travels inside the token issued by LoginMaster, and Data Alchemy builds its access control on that role, distinguishing administrators, tenant administrators, managers, users, technicians and application accounts. Changing someone's role is a console operation.
Each customer has a dedicated tenant with isolated data, and the LoginMaster tenant can be installed in the customer's own datacentre. User credentials are entrusted neither to the application nor to non-EU third-party cloud services.
No. The pattern — the application does not implement authentication, it delegates to an identity provider that federates corporate providers and local accounts — applies to any multi-tenant SaaS that must serve both customer employees and licence-free external users.
Want the same SSO for your application?
If your product needs to authenticate employees with Entra ID or Google Workspace alongside external users without licences, LoginMaster does exactly what it does for Data Alchemy. Let's talk.