FAQ

Frequently asked questions from teams integrating azuma doa. Each answer links to the full documentation for the topic — this page is a fast-answer layer on top of it, not a replacement.

Getting Started & Developer Portal

How do I get access to the Developer Portal?

You need an azuma doa account assigned to at least one Developer Tenant. The easiest way is to contact us and we'll create the Developer Tenant and send an invitation. See Developer Portal.

What can I configure myself vs. what requires contacting azuma?

Self-service, via the Developer Portal: application configuration, roles/permissions/licenses, tenant settings (password policy, token settings, mailing, Device Binding config), and per-user login-method overrides. Contact-us / opt-in: SAML, HSM, HIN, Google/Apple token exchange, and creating a new Developer Tenant. See Developer Portal, SAML, HSM Usage.

How is the Developer Portal itself secured?

Authentication via azuma doa's own identity provider (email/password, with TOTP multi-factor authentication strongly encouraged), optional IP-filtering to restrict access to specific network ranges, and role-based access control with four roles: Admin, Developer, Support, and Reader. See Security & Access.

Multi-Tenancy, Applications & Roles

What's the difference between single-tenant and multi-tenant/multi-hierarchy setups?

In a single-tenant setup, users belong to your tenant and are only available within it — the most common scenario. Multi-tenant, multi-hierarchy setups make users belonging to your organization available across all tenants and sub-tenants, for complex organizations like hospital structures. See Overview.

What are Applications, roles, permissions, and licenses?

An Application organizes an integrated product and has a permanent, globally unique short key (used to prefix its roles/permissions/scopes). A permission is an atomic capability and can't be assigned directly to users. A role bundles permissions and is assigned to users. A license authorizes usage of a component or function and is also assigned to users. See Integration Concept.

Can I restrict one specific user to only certain login methods?

Yes — a per-user allowlist override, enforced for mobile (Device Binding) login. It's restrict-only: it's always capped by the tenant's configuration, so a method disabled for the tenant can never be enabled for an individual user through an override. See Per-User Login-Method Overrides.

Authentication Methods

Which authentication flows does azuma doa support?

Device Binding for mobile (conforms to the BSI TR-03161 "substantial" security level, via Apple App Attest / Google Play Attestation), the Authorization Code Flow (OAuth 2.0 / OpenID Connect) for mobile and web, and the Client Credentials Flow for backend-to-backend and admin-API authorization. See Overview.

Which MFA methods are available?

Device Binding (mobile only), Time-based One-Time Password (TOTP), Username/Email + Password, Passkeys, and Biometrics — enabled and configured per tenant. See Multifactor Authentication.

Are Passkeys available today?

Yes, for flows already integrated with Device Binding. Passkeys for web-based flows are coming soon. See Passkeys.

How does Health-ID (GesundheitsID) login work?

Through azuma mimoto as an authentication provider. You enable the mimoto provider and configure the allowed mimoto audiences in the Developer Portal; the used mimoto client IDs then need to be configured in azuma doa Tenant Administration as allowed Audiences. See Health-ID (mimoto) and Device Binding.

Compliance & Security

Is azuma doa itself BSI TR-03161 certified?

The product isn't separately certified, but customers using azuma doa have successfully passed the BSI TR-03161 audit process without conditions — a proven, compliant foundation for secure identity management. See Overview.

What is HSM support, and do I need it?

Hardware Security Module (HSM) support is a Premium, opt-in feature that offloads cryptographic key management — token (JWT) signing and identity-proofing signatures — to dedicated hardware, so keys never leave the secure hardware boundary. It helps meet strict regulatory requirements like BSI TR-03161. Contact us to opt in; once enabled for your tenant, you can toggle it yourself. See HSM Usage.

Migrating Users In & Out

Can I import existing users into azuma doa?

Two paths: a seamless Data Migration, where your existing login page offers both an azuma doa login (for new users) and a legacy-credentials login that silently creates a matching azuma doa account; or a one-time Data Import via the API, using Account Reference IDs to preserve links to your old account IDs. Bulk account creation via API is currently limited — contact us for details. See Import Users.

What if I want to leave azuma doa later?

Fully supported. azuma doa is built on the open-source Ory stack (Kratos/Hydra), which is a reasonable reference point if you need to self-host a replacement. Your tenant's permissions, roles, and users can be exported via the API — but passwords cannot be exported, so plan for a password-reset step during migration. See Opting Out.

Email & Branding

Can I send emails from my own domain?

Yes — configure a custom SMTP server (URL, port, credentials, from-address, from-name) per tenant in the Developer Portal, and all outgoing verification, password-reset, and notification emails go through it. See Mailing Configuration.

Can I customize verification and recovery emails?

Yes, via Generic Template Mode (recommended over the default azuma-branded templates): a shared Base Template for structure plus Specific Templates for each email type (Verification, Recovery, Account Authentication Method Changes), with Liquid-based parameter and locale substitution. See Mailing Configuration.