Application users and authentication

Two different kinds of account

Your Amazi account controls access to Amazi projects and product features. Users of an application you build have whatever authentication and permissions that application implements. Signing in to Amazi does not automatically create an account in your application.

Likewise, inviting a collaborator to a project does not automatically make them an administrator of the published app. See Collaboration and access for project roles, and Account and security for your Amazi identity.

Describe the protected workflow

When requesting authentication, specify who should sign in, what each role may do, and which data belongs to each user or organization. Ask for server-side access checks, not only hidden interface buttons.

For example:

Members may see only their own bookings. Staff may manage bookings for their assigned location. Verify that a member cannot open another member's booking by changing its URL.

The available sign-in methods depend on the application's implementation and connected services. Do not assume a particular email, SMS, or social provider is already configured.

How Amazi verifies signed-in behavior

When the requested change needs authenticated testing and no suitable test account exists, Amazi can create a clearly identified verification user with the minimum necessary role and test data. This is part of the requested verification and should not require your personal password or another ceremonial approval.

Verification must use the application's real sign-in and permission checks. Amazi must not disable authentication, add a backdoor, reset a real customer's password, or impersonate an existing user to obtain access.

If external verification or an unavailable provider prevents sign-in, the result should say which scenario remains unverified.

Test users are still real database records

The managed database is shared with production. Dedicated verification identities and fixtures therefore need a clear scope and cleanup plan. Testing should not send real invitations, purchases, or notifications to unrelated people.

Ask for evidence of the relevant role and action: signed-in navigation, successful permitted behavior, denied forbidden behavior, and persisted results where required. A login page loading successfully does not prove that the protected workflow works. See Testing and verification.