Authentication

Authentication verifies a user is able to access your application, but doesn't define what they can see or alter — see Authorization for that side. This page covers the admin-facing tasks: customizing login settings, forcing a user out, and troubleshooting a login problem. For the end-user conceptual model — 2FA setup, OAuth account linking, password resets, session security — see Authentication.

Customizing Admin Settings

Modification of any of these settings will require the appSettingSchemasModify admin right on the user profile. This is granted by default to super admins upon access to the application, but may be shared by other admins. To see the admin rights a user has, view their profile under Admin → Users and check the Admin Rights section.

The following may be customized to override the defaults:

• Allow Registration - Allow users in the allowed domains to create unregistered accounts and automatically receive emails to register them without having an admin approve the request. (Default: false)
• Max Login Attempts - Number of failed login attempts before an account is set to "hard lock." Once an account is hard locked it will need to be unlocked by someone with usersUpdate admin rights. (Allowed range: 1–20. Default: 5 tries)
• Lockout Time: How long, in seconds, a failed-attempt counts toward the lock. Failures older than this drop out of the count, so the lock self-clears after a quiet period. (Allowed range: 300–3600 seconds.)
• Two-Factor Authentication: a single on/off setting that requires SMS 2FA for every login, with no grace period.

Allowed Domains is not a setting on this page. The email allowed-domains list is environment-only (NUXT_ALLOWED_DOMAINS) and is managed from the support portal's My Environment page, so invite validation, mail delivery, and CSRF origin can't drift across DB-vs-env sources.

Active Login Methods are not toggled here either. Which methods appear (Username/Password plus any of Google, GitHub, Microsoft, Keycloak) is derived from which OAuth client IDs are present in the environment (NUXT_OAUTH_*_CLIENTID). Username/password is always available; configuration of the SSO alternatives should be handled with Aptli's devs (contact@aptli.io).

Session, CSRF, and session-expiry timeouts have moved to the provisioning portal and are shown read-only on the settings page; they are no longer edited here.

Force Logout

From Admin → Users, a user can be hard-locked and logged out from the actions menu against each row.

Troubleshooting Login

If a user is having trouble logging in, start by finding their profile at Admin → Users. Login problems usually come down to one of a few possibilities:

• Deleted account. If you can't find the user account by scrolling or filtering by case-sensitive email, they may have been deleted. If you hold the viewDeleted right, a Show Deleted toggle reveals archived accounts. With usersCreate, you can undelete the account from its actions menu.
• Hard lock. Users can be hard-locked automatically (too many failed password attempts) or manually. Look for a Hard Lock badge on their profile; with usersUpdate you can unlock it.
• Email not validated. The user's profile shows a validation date once they've completed it. A 10-minute-expiry link is sent to activate the account; until it's clicked, the user can't log in through any method, including SSO.
• Bad domain. As noted above, users can't be added from an unrecognized email domain. If a legitimate domain changes, external addresses can still be added manually by an admin with usersCreate (this bypasses the domain check).

Changes to user profiles take effect immediately once submitted.

Further questions can always be answered by your support contact.