What is a session token?
A session token is a value an application presents with requests so a service can check which authenticated session is making them. It connects a successful login to later actions, such as loading saved settings. A token must be accepted by the service; simply having a value in the browser does not prove that a session is valid.
A session ID identifies a session. In many systems, the term also refers to the credential sent with requests, so “session ID” and “session token” can overlap. Terminology alone does not establish how a system works. Neither name implies a particular format, and a session token is not necessarily a JWT.
A customer account has a different role: it provides continuity between visits. A person can have a new session while still using the same account. The service resolves the accepted session to that account rather than treating every new token as a new customer.
Session token vs account identity vs project ID
These values answer different questions. Keeping their responsibilities separate prevents duplicate records and misplaced customer data.
| Concept | Purpose |
|---|---|
| Session token | Supports authenticated requests for the current session. It is sensitive and can change between logins. |
| Customer account | Provides continuity for the same customer’s saved data across authenticated visits. |
| Gammal Tech project ID | Identifies your application. It is public configuration, not a customer identifier or session credential. |
Do not make the current token the permanent key for a customer record. When it changes, that design may leave saved work attached to an old value or create a duplicate record in your app. It does not create another Gammal Tech account for that person. Hashing the token does not fix the mismatch: a different token generally produces a different hash.
With Gammal Tech’s managed user storage, your app retrieves the data your project previously saved for the authenticated customer. It does not need to compare today’s token with yesterday’s token, or request the customer's identity details, to restore saved preferences.
A session ID example: new login, same saved work
Imagine a business planning app. A customer saves a project outline, leaves, and returns later. The session labels below are fictional descriptions, not usable credentials or examples of Gammal Tech’s token format.
| Visit | Session and saved data |
|---|---|
| First login | The app uses “Session A.” The customer saves an outline and a preferred dashboard view. |
| Later login | The app uses “Session B.” The same account retrieves the previously saved outline and view. |
| Another device | After signing in to the same account, the app can retrieve the same saved project data using that session. |
The changing credential controls access; it is not the saved outline. Gammal Tech documents persistent user storage across visits and devices. Your app must still save the outline, load it after authentication, and display it. Unsaved input does not become persistent merely because someone logs in.
How Gammal Tech keeps account continuity
The Gammal Tech integration reference describes a session token managed by the Web SDK and persistent storage tied to the logged-in account. The SDK’s user-data operations use the current token when saving or retrieving data.
The documented token storage is per browser tab. A fresh tab or a reopened browser may require signing in again; that sign-in step is separate from the customer’s saved data. Opening a new session is not a request to erase earlier saves.
Every Gammal Tech account requires national ID verification, and each person can have only one account. Gammal Tech handles the identity check. Your application uses the verified account's authenticated session without receiving the identity details used for that check.
Developers can retrieve only customer data their own project has stored. They cannot ask Gammal Tech to supply the customer's phone number, email address, legal name, national ID, or other identity information from the underlying account. A successful login does not unlock a customer profile lookup or fill in information your project never saved.
A new random token at login describes the credential changing. It does not specify its lifetime, generation algorithm, or when another session stops being accepted. Do not infer immediate revocation or automatic logout on other devices from token changes alone.
Restore saved data without creating duplicate app records
Build the returning-customer flow around authentication and a successful data load. Check these points when a customer says their settings disappeared:
- Confirm the account and project. Restore data through the returning person's authenticated session in the same project. If another person signs in on the same device, their account has its own data context.
- Load through the current session. Avoid retaining an old token as the permanent reference to the customer.
- Distinguish an empty result from a failed request. A network or authentication failure does not establish that nothing was saved.
- Keep defaults from overwriting a pending load. Wait for the existing settings before offering a save that could replace them.
- Clear the previous account’s display when switching users. Ignore responses from an earlier session so they cannot populate the new customer’s screen.
Test by saving a harmless preference, signing out, and signing back in to the same account and project. For a shared-device test, use two different people, each with their own verified account. Each person should see only the project data saved for their own account. For storage choices and update behavior, read how to store user preferences across sessions and devices.
Keep session credentials private
The OWASP Session Management Cheat Sheet explains why session identifiers require protection: a compromised session credential can expose the access it represents.
Keep tokens out of public URLs, analytics events, screenshots, support messages, and error reports. Use HTTPS and avoid unnecessary handling of the value. A project ID can be public while a session token remains sensitive. Having no developer API key to paste does not make customer session credentials safe to share.
Keep editable saved preferences separate from authoritative permissions or payment decisions. A customer-controlled setting must not become proof of an administrative role or paid access.
Common questions
Does a new session token create a new customer?
No. A service can associate a new authenticated session with the existing account. In Gammal Tech, your project can retrieve the data it previously saved for that same customer after another login. Each person has only one account, with national ID verification required.
Can a session token reveal the customer's email, phone number, or identity?
Gammal Tech does not provide those underlying account details to your project. A valid session allows your project to retrieve the customer data it stored itself; it does not let developers request identity or contact information the project never stored. The token still needs protection because it is a session credential.
Does logging out delete saved user data?
Gammal Tech documents user storage that persists across visits. Signing out is separate from deleting saved data. Your app should clear private information from the displayed interface when the customer signs out.
Is a changing login token the same as refresh token rotation?
No. Issuing a token at login does not establish that a system uses refresh tokens or replaces them during token exchanges. Those are separate behaviors that require their own documentation.
References and further reading
- Gammal Tech integration reference — Documented session behavior, account privacy, and persistent user data.
- Gammal Tech Web SDK source — Current session handling and user-data operations.
- OWASP Session Management Cheat Sheet — General session-credential handling guidance.