One profile with separate sessions
The website reads the current user through /api/v1/me; it adds no Web-only user table. An account can have multiple sessions, and revocation targets a session identifier. Phone and browser can display the same profile while retaining independent login lifecycles.
A first website visit still requires sign-in. Cross-site single sign-on would require a separate authorization and callback design. Do not send a phone token to a page in a URL: query parameters can enter browsing history, access logs, and onward redirects.
Language and time zone are saved as profile fields. Distinguish an anonymous visitor's local language choice from a signed-in user's server preference. Check the result of a server-side preference update and report a failure to the user.
The Web server manages browser credentials
The same-origin BFF receives requests from pages and calls the configured App API. Access tokens, refresh tokens, and the device key use HttpOnly cookies scoped to /api/session, with Secure enabled in production. Client JSON and localStorage do not expose or retain these credentials.
Writes check Origin and request source, and business endpoints use an explicit allowlist. Deploy with HTTPS and an accurate site URL. HttpOnly restricts script access to cookies; origin checks, API authorization, and safe page scripts are still required.
The native app retains its access token in memory and its refresh token through the secure-storage wrapper. Non-sensitive preferences can use ordinary local storage. Passwords, verification codes, and session credentials are kept separate from those settings.
The diagram explains storage and authentication boundaries. It does not depict cross-site single sign-on or a production deployment.
Restore identity before deciding what a reload means
A reload clears page memory while cookies may remain valid. Account components should start in a loading state, request the profile through the session endpoint, and then choose between account content and sign-in. Checking the initial empty memory state would misclassify a recoverable user as anonymous.
The website attempts refresh-token rotation when short-lived credentials are missing or expired, then reads /me again. Invalid sessions clear cookies. Timeouts, rate limits, and temporary backend failures produce a recoverable error. Otherwise ordinary network disruption would repeatedly ask users for their password.
Refresh coordination has a deployment limit
Several tabs can request profiles and bookmarks together. If each consumes the same refresh token independently, later requests may encounter an already-used token. Browsers with Web Locks serialize session requests, while the server shares a rotation result within one Web process.
Process-local coordination does not cover multiple Web instances. Before horizontal scaling, introduce shared coordination and verify multiple tabs, cookie updates, and concurrent rotation again. Single-instance checks do not establish distributed behavior.
Mutations establish identity before being sent once. If the response is lost after dispatch, the client cannot tell from an error alone whether the database saved the change. Operations without idempotency guarantees must not be automatically replayed.
Account-integration acceptance
Sign in with two independent clients and one test account. Confirm matching profiles and different session identifiers. Change language and read the backend value. Revoke one session, attempt its recovery, and check the other session against the defined API behavior.
Also perform a real reload with only refresh credentials remaining, make the API temporarily unavailable, call protected endpoints after logout, and attempt a different App context. Add repeated-save checks for bookmarks. Screenshots show page state; rotation and permission results need actual requests.
The registration page requires published terms and a privacy policy. Registration verification and real email recovery need a working delivery channel. Verify these conditions separately. Implementation references are the App API and Next.js authentication documentation.