Add sign-up and sign-in

Add authentication when an app needs to recognize a person: for example, to show private bookings, saved work, or a personal dashboard. App-user accounts are separate from Ahamo Workspace membership. Someone can sign in to your app without gaining access to its Ahamo project.

Authentication establishes identity. Access rules decide what that identity may see or change. A signed-in customer must not automatically gain access to another customer's records or a staff-only action.

Define public and private areas

List the behavior for three states before building:

• what anyone can view;
• what a signed-in person can view or change;
• what the app must deny.

For a booking app, services can remain public while upcoming bookings require sign-in. Keep staff access outside the first change unless its actions and permissions are fully defined.

Use Plan for an app that already stores data:

Plan email-and-password sign-up and sign-in for this booking app. Keep service browsing public. Require sign-in for upcoming bookings. A customer may see only their own bookings. Explain what happens to existing bookings, and do not build yet.

Review how records become associated with an account. Do not connect private records to a newly created account merely because an email address matches.

Build the complete account flow

Approve the plan, then ask Ahamo to add sign-up, sign-in, sign-out, protected navigation, and clear invalid-credential and expired-session states. State where a person returns after signing in. A hidden button is not protection; the app must enforce access when the route or data is requested.

In Runtime → Auth, select the environment you are testing. The pane reports configured providers and session counts when inspection data is available. Use it to confirm that you are looking at the intended environment, not to administer individual users.

Email verification is available only when its policy and delivery setup are enabled for that environment. Do not promise a verification email until the production environment can deliver it. The Runtime provider summary does not by itself prove that email delivery works.

Test two users and signed-out access

Use fictional accounts in a private browser window or separate browser profiles:

1. Create account A, sign in, and create one private booking.
2. Sign out and open the protected address directly. The app should request sign-in without briefly showing private content.
3. Sign in as account B. Confirm account A's booking cannot be listed, opened by its address, or changed.
4. Enter invalid credentials and confirm the message helps recovery without revealing whether an email has an account.
5. Clear or expire the session and confirm protected navigation returns to sign-in rather than looping.
6. Sign back in as account A and confirm the booking is still available.

Repeat the flow on the published app because production has its own provider and session state. Never put passwords, session values, or real customer records in prompts, screenshots, or logs.