Passwordless web authentication: sessions, privacy, and saved data

What passwordless authentication means here

For a website using Gammal Tech, passwordless describes the absence of an application-specific password. Your website opens the hosted sign-in popup instead of collecting a separate password for the customer.

After successful sign-in, the application receives a session credential and can check whether the session is valid. That credential still needs protection. The benefit is that your application does not have to collect or store the user’s account password for this flow.

How sessions behave

The documented session is kept per browser tab. A user who opens a fresh tab or reopens the browser signs in again. A returning user can then retrieve the data already saved for their account and your project.

Do not describe local sign-out as a promise to end every session on every device. If your product needs organization-wide or cross-device session controls, confirm those requirements separately before promising them to customers.

Why saved data survives sign-out

Gammal Tech provides persistent user data for each account in your project, with a maximum size of 1 MB per user. This can hold preferences, bookmarks, progress, and other compact app information.

For example, a user may choose a language and complete several lessons on a laptop. After signing in on another device, the app can retrieve that saved state. The session has changed, but the saved experience remains.

This does not mean the service is a shared company database or a file archive. Choose the information that fits the individual customer experience and the documented size limit.

Account privacy and business permissions

Login verification confirms that a user is signed in without returning their Gammal Tech email, phone number, or identity documents to your application. If your product asks for contact or profile information separately, that is an additional collection by your business.

Sign-in also does not decide whether a person should see a company invoice, manage a team, or receive a paid feature. Those product permissions need their own reliable controls. A remembered preference should not be treated as proof of payment or administrative authority.

What to plan before launch

• Customer expectations. Explain when sign-in is needed and give users a clear way to sign out.
• Returning visits. Check that preferences reappear after a new sign-in and on another device.
• Project setup. Use a verified owner account and register up to four HTTPS domains. Bare and www domains count separately.
• Existing accounts. Plan how current customer records relate to the new sign-in flow; account migration is not automatic.

Authentication pricing

Currency guide: Listed EGP prices are the billing amounts. USD figures are approximate, using USD 1 = EGP 51.78, the calculated midpoint of Banque Misr’s USD buying and selling rates on 24 September 2026. Your payment provider’s exchange rate and fees may differ.

The code allowance includes codes sent during login and checkout identity verification, and resets monthly. Paid usage comes from the project balance: add funds to your personal wallet, then transfer them into the project. The first project is free; additional projects have a one-time fee shown in the Console.

Common questions