Open source
Components that almost every system needs, we build once and in the open. Currently two projects: CentralAuth for authentication and SancMeld for sanctions-list screening.
One authorization server and one BFF for all projects
Every new project usually writes its own login, session management and API gateway from scratch. CentralAuth turns that around: a new project simply registers, and its frontends and backends are secured from day one.
New project
Login, session refresh, logout, permission checks, an API gateway — the same work in every new project. Here it is replaced by registering the application.
A code, a name and the internal address of the service. The /bff/{code} path is created automatically.
The service runs on the internal network with no exposed port. From the outside, the only way in is through the BFF.
Calls go to /bff/{code}/… with the login cookie. Not a single line of authentication code is added to your project.
One place where login is handled for all applications.
The token never reaches the browser. Ever.
A new application is one record, not another piece of configuration.
Revoked access takes effect immediately, not when a token expires.
How it works
The frontend talks exclusively to the BFF and identifies itself with a signed HttpOnly cookie. On every request, the BFF verifies that the session is still valid, and only then issues a short-lived token for the target API. If an attacker manages to run foreign script in your application, there is nothing to steal — and revoked access takes effect immediately, not once a token expires.
At the same time, the BFF is a transparent proxy — it forwards requests exactly as the frontend sent them. During development and debugging you therefore see the real API calls, and when hunting a bug there is no need to reconstruct what actually happened between the layers. The whole solution is meant for projects where a custom BFF as another application layer does not make sense — instead of every project building and operating its own, one central BFF takes its place.
Browser
HttpOnly cookie
BFF proxy
verifies the session, issues a JWT
Protected API
Bearer token
Second project
Screening against the EU, UN and OFAC sanctions lists
A .NET solution that uses a set of scheduled cron jobs to continuously download the available sanctions lists and search them for matches. It includes a prediction mechanism built on ML.NET that helps assess how relevant a found match is.
Working with us
The code is open, so you can do everything yourself. If you want, we can help — from support all the way to a fully managed service.
You run the solution yourself, with guaranteed help from us — consultations, troubleshooting and assistance with upgrades.
We deploy the whole solution to your server or your cloud and take over its operations — updates, monitoring and security patches.
Prefer not to run anything? Purchase a tenant on our instance and use the solution as a service.
An authorization server is exactly the kind of component nobody wants to write themselves, yet everyone needs to be able to look under its hood with confidence. Closed code does not offer that trust.
You can deploy and operate the solution entirely on your own — or pick one of the collaboration options above.
Built on the OpenID Connect and OAuth 2.0 standards. If you ever decide to leave, you leave with a standard protocol, not with our convention.
You can walk through the entire authorization flow line by line — including your own security audits.
OpenIddict and ASP.NET Identity. We did not reinvent cryptography or protocols — we combined them into a whole that can be deployed in one go.
The authorization server, the BFF proxy, application registration and administration all work. We are still polishing the solution for production deployment and will not claim otherwise.