User Accounts and Organization Access

Understand AISIX Enterprise account registration, password recovery status, organization ownership, and the current administrator model.

AISIX Enterprise separates a user account, which signs in to the control plane, from an organization membership, which grants access to one organization. Creating an account alone does not assign an organization role. A user can belong to multiple organizations with a different role in each one.

How Accounts and Access Fit Together

The dashboard uses Better Auth for account registration, sign-in, sessions, and optional Google or GitHub sign-in. The control-plane API checks the signed-in user's identity and their membership in the selected organization before authorizing organization resources. AISIX stores authentication records and organization membership records separately.

Concept	What it controls
User account	The identity used to sign in, including an email address and, for email sign-in, a password.
Organization	The boundary for members, roles, billing, and shared administration.
Organization membership	The user's role in one organization. The same account can have different roles in different organizations.
Admin token	API access scoped to one organization; it is created by an organization owner and does not grant deployment-wide access.

For the relationship between organizations, environments, and caller API keys, see How AISIX Enterprise Composes. A user's control-plane role is separate from the permissions of a caller API key used to send gateway traffic.

Create the First Account and Organization

Open the control-plane URL and select Create an account.
Register with an email address and password, accept the user agreement, and sign in. Google and GitHub sign-in appear only when those providers are configured.
If you do not belong to an organization, create one on the organization selection page. AISIX assigns the account that creates it the owner role in that organization.

The first registered account has no special deployment-wide status. The owner role is assigned when an organization is created, not because the account was registered first. Another user who creates a separate organization becomes the owner of that organization. Neither owner automatically gains access to the other's organization.

Email/password registration is enabled in the current control plane. The signup form requires at least 12 characters, including uppercase and lowercase letters and a digit; Better Auth's server-side configuration enforces a minimum of 12 characters. Operators should not assume the form's additional character rules are a server-side password policy.

An account created with email and password signs in from the Sign in page. The dashboard also offers Google or GitHub sign-in when the respective OAuth credentials are configured. A signed-in user who knows their current password can open Settings and choose Change password. That action requires the current password and revokes the user's other sessions.

Forgotten Passwords: Current Status

Self-service password recovery is not currently available. The Forgot? text on the sign-in form links back to /login; it does not open a reset request form. Although AISIX uses Better Auth, its current emailAndPassword configuration has no sendResetPassword callback, and the dashboard has no request-reset or reset-password page. Merely enabling email/password sign-in, or configuring SMTP outside the application, does not make password recovery work.

Better Auth setting or application step	Current AISIX status
`emailAndPassword.enabled`	Enabled for email/password registration and sign-in.
`emailAndPassword.minPasswordLength`	Set to `12`; this is a password-length rule, not a reset-mail configuration.
`emailAndPassword.sendResetPassword`	Not configured. No application callback sends a reset link.
Reset request and completion pages	Not implemented in the dashboard; Forgot? returns to the sign-in page.
Reset-token lifetime and session revocation on reset	AISIX does not configure `resetPasswordTokenExpiresIn` or `revokeSessionsOnPasswordReset`. Better Auth defaults are not an operational recovery policy while the reset flow is absent.

Better Auth's password-reset flow requires the application to provide emailAndPassword.sendResetPassword so a reset link is delivered to the account's email address. The application must then call requestPasswordReset from a request form, accept the reset link on a page, and call resetPassword with the link's token and the new password. AISIX does not currently provide that complete flow or an operator setting that activates it. The authenticated Change password action is different: it requires the existing password and cannot recover a forgotten one.

Do not rely on the Forgot? link when planning account recovery for a production deployment. A future password-reset implementation must include an email delivery service, the Better Auth callback, the request and completion pages, and operational checks for delivery and token handling. This describes what implementation would require; these steps are not available as current AISIX configuration instructions.

Organization Roles

AISIX Enterprise has three built-in organization roles. The product calls the basic role member; there is no built-in role named user.

Role	Current organization-level access
`owner`	Full control of the organization, including billing, member role changes, member removal, and admin token management.
`admin`	Read and write access to organization resources; owner-only actions such as member role changes, member removal, and admin token creation remain restricted.
`member`	Read-only access to the organization's resources, except audit events.

These roles apply within an organization. An owner can invite other people and assign roles to their memberships; an account does not inherit the owner's access merely because it registered earlier or later. See Members for invitations and directly created, non-sign-in members. See Roles and Custom Roles for custom permissions and environment access grants.

No Platform Administrator Role Today

The current release has no deployment-wide Platform Admin or super administrator account or role. In particular, the first account is not a platform administrator, and an organization owner cannot automatically administer every other organization. Organization-scoped admin tokens follow the same boundary.

A platform-wide administrator capability is planned for a future roadmap phase. It is not part of the current permission model; no release date or final permission scope is specified here. Until such a capability ships, design operational access around organization owners and memberships rather than assuming a hidden platform administrator exists.