Every auth method, one authentication flow
Maesn abstracts OAuth, API keys, database credentials and 2FA behind a single flow, and handles multi-company selection, headless integration and signed callbacks, so you connect a customer once instead of learning every system's login.
Provet
ProvetWhat is unified authentication
Before you can read or write a single record, every customer has to connect their system, and every ERP or accounting platform authenticates differently. One uses OAuth with a redirect screen, the next wants an API key pasted into a form, another needs database credentials or a second factor, and some ask the customer to pick a specific company before anything works at all. Building and maintaining a separate login for each one is where integration projects lose their first weeks.
Unified authentication puts one flow in front of all of it. You send a customer into a single Maesn authentication, Maesn runs whatever the target system actually requires behind the scenes, and hands you back one account key you use for every request afterwards. The method, the number of steps and the company selection all stay on Maesn's side, so your integration authenticates the same way whichever system your customer runs.
It is the entry point to the rest of the Unified API. The same two headers that authorize a connection authorize every call you make afterwards, so once a customer is connected you read and write their data through one standardized set of endpoints and one common data model, whichever system sits behind it.
Every system logs in differently
The same task, connecting a customer, looks different in every system: a different auth method, a different number of steps, a different token lifetime and a different place you have to build the UI.
Two keys, one flow
You authenticate against Maesn, not against each system. Two headers carry every request, and one endpoint runs the customer's login for you.
The key you get when you sign up with Maesn. It authenticates every request as coming from your platform, whichever customer that request is for.
Issued once a customer authenticates, unique to that customer and target system. A customer can hold several of these, one per connected system.
Every method, abstracted
OAuth, API keys, database credentials and 2FA are all handled behind one flow, so you never implement a system's login by hand.
Multi-company built in
Where a system needs the customer to pick a company or environment, that step is embedded in the same flow and stored for later requests.
Hosted or headless
Use Maesn's customizable authentication pages, or run a fully headless flow and build the UI yourself with your own user experience.
Signed callbacks
Verify that a callback genuinely came from Maesn with an HMAC-SHA256 signature, and receive the account key in the body instead of the URL.
GET /auth/datev-uo?environmentSelection=true&callbackUrl=https://your-app.com/callbackx-api-key: YOUR_API_KEY
Multi-company, one click for the customer
Some systems will not let a customer connect until they choose a specific company or environment, and reaching that choice can take several authentication steps. DATEV is the clearest case: the customer authenticates once with a short-lived token, sees the list of Mandanten they have access to, selects one and then authenticates a second time for that specific company.
Maesn embeds all of it in a single flow. Set environmentSelection=true and the customer is shown a selection page, picks their company and is redirected back into your app with one account key. The stored selection is reused on every later request, so you never send a company identifier by hand, and you never build the selection step yourself. Whether or not a given system needs a choice, your integration triggers the same one authentication.
The customer clicks once, picks their company from an embedded list and lands back in your app. Every multi-step detail stays on Maesn's side.
Trust the key that comes back
After a customer authenticates, the account key is delivered to your platform. Signed callbacks let you prove that delivery genuinely came from Maesn.
- accountKey
- The key for the authenticated customer
- ts
- When the account key was created
- maesn_signature
- HMAC-SHA256 signature to verify
payload = `accountKey=${accountKey}&ts=${ts}`
expected = hmacSha256(signingSecret, payload)
isValid = expected === maesn_signatureSignatures match, so the callback came from Maesn. Callbacks older than your chosen window are rejected.
You generate a signing secret once for your tenant, and that is the only time it is returned, so it is stored on your side and nowhere else. Passing include_signature=true when you start authentication tells Maesn to sign the callback, and every callback then arrives with a timestamp and an HMAC-SHA256 signature you recompute against your secret. A signature that does not match, or a callback that is older than the window you allow, gets rejected before it reaches your logic.
The delivery itself is tiered too. Instead of a redirect that carries the account key in the query string, you can have Maesn deliver it in a request body or as a webhook event, so the key never lands in standard URL logging. If a secret is ever exposed, you rotate it by generating a new one, which invalidates the old secret immediately, so update your configuration before you rotate.
One flow, less to build and maintain
- Implement every auth method yourself
- Build a company picker per system
- Track token refresh and expiry
- Rebuild the login for each new system
- One flow for every auth method
- Company selection embedded for you
- Tokens refreshed and sequenced for you
- New systems use the same flow
Authentication is rarely a one-time cost. Tokens expire, systems change their login, and a burst of parallel traffic during a refresh can break the connection and force the customer to re-authenticate. Maesn sequences requests per tenant so a refresh stays intact, part of how asynchronous processing paces traffic to each system. You build one authentication, and it keeps working as your customer base and the systems behind it change.
Common questions
Build once on the Unified API.
See how unified authentication works for your integration, or dive into the technical reference.