The Quickstart and every Playground button on this site log you in interactively - a browser redirect to Ason's identity provider, a human clicking "Login". That's the right flow for exploring the API yourself, but it's the wrong flow for your production backend, which needs to call Ason without a human in the loop.
System User: machine-to-machine via Zitadel
Ason's identity provider is Zitadel. Interactive Users log in through Zitadel's normal OIDC flow, with sessions that refresh automatically like any browser login. Machine-to-machine access works differently: it's not a self-service OAuth2 flow you run yourself.
The flow:
- Ason provisions a system user for your tenant in its Zitadel instance and generates a machine-to-machine access token for it (via the OAuth2
client_credentialsgrant, on the Zitadel side). - Ason sends you that token directly. Your backend never calls Zitadel's token endpoint itself, and you never see a client ID or secret - you just get the resulting token.
- Your backend calls the Ason API with that token as
Authorization: Bearer <token>- the exact same header every interactive-login request uses. From the Ason API's point of view, there's no difference between a system user and a logged-in human; both are just a valid Zitadel access token.
Getting a system user
System users are provisioned by Ason, not self-service through the API - talk to us to get a token issued for your tenant.
Token lifetime
The system user token Ason gives you is permanent - it doesn't expire, so there's no refresh flow to build for it. Store it once (e.g. in your backend's configuration or secrets store) and use it for every request. This is different from interactive User sessions in the Ason frontend, which go through Zitadel's normal OIDC login and refresh automatically.
Should you also create Ason users?
A system user authenticates your backend, not your end users - it doesn't by itself decide what an individual employee or HR admin is allowed to see. In both integration models (Embedded and Whitelabel), the recommended pattern is: your platform's own IAM keeps deciding who can do what, your backend enforces that with its own logic, and it's the backend (authenticated as the system user) that talks to Ason on the user's behalf. You generally don't need to create one Ason user per end user just to make API calls.
Where this shows up
- Embedded Into Your Platform - the system user in the embedded architecture
- Standalone White-Label Solution - the system user in both white-label IAM options
- API Reference - every endpoint accepts a system user token exactly like an interactive one