Per-User Login-Method Overrides
By default, the set of login methods a user may use (e-mail, username, ID, Health-ID, passkeys, biometrics, Google, Apple) is configured per tenant in the tenant's authentication flow settings.
Per-user login-method overrides let a tenant admin further restrict an individual user to a subset of those methods — for example, allowing a particular user to sign in only via Health-ID.
How it works
A user's override is an allowlist:
- Inactive (default): the user inherits every login method enabled for the tenant.
- Active: only the methods explicitly selected in the allowlist are permitted for that user.
The allowlist is restrict-only: it is always capped by the tenant configuration. A method that is disabled for the tenant can never be enabled for an individual user through an override.
Per-user overrides are enforced for mobile (device-binding) login. The full account lock-out (disabling a user entirely, across all channels) remains available via the user's account status.
A locked/disabled account is rejected before any per-method override is evaluated. Precedence is: account disabled → per-user allowlist → tenant configuration.
Managing overrides
Dashboard
A tenant admin can view and set a user's overrides in the developer portal: open the tenant → user → Settings tab and use the Device Binding login methods card. Methods the tenant has disabled are shown greyed out (they cannot be enabled per user). The card is shown only for users that belong to the tenant, and only when device binding is enabled for the tenant.
Admin API
The same settings are available programmatically on the tenant Admin API (client-credentials, tenant-admin scope):
GET /account/v1/{id}/flowOverrides— read the user's allowlist plus the tenant's effective login flags.POST /account/v1/{id}/flowOverrides— set (allowlistActive: true) or clear (allowlistActive: false) the allowlist.
See the Admin-API Swagger documentation (linked from the azuma doa overview) for the full request/response schema.