Sessions

Customer identity and sessions in Edge Kit, including server checks, anonymous access, session revocation, and private application data.

A session lets your application recognize a customer across requests after they sign in. Edge Kit connects Better Auth sessions to server-rendered pages, client navigation, and private operations, so the same identity is available throughout the application.

Account: owns the profile, subscriptions, and product data.
Session: represents access from a particular browser or device.

Signing out ends that access without deleting the account.

Session lifecycle

After a successful sign-in, Better Auth establishes a session and manages its cookie. Subsequent requests carry the cookie to the application, where the server can resolve the customer before reading or changing private data.

The kit's page layouts load the current session on the server and provide it to the client. This lets the initial interface reflect the customer's identity while the browser takes over interactive navigation.

Sessions can expire or be revoked independently of the page currently visible. A customer may leave a tab open, sign out on another device, or reset their password. Every private operation should therefore check the current session even when the surrounding page already did so.

Access policies

Authentication establishes who is making a request. Authorization decides whether that identity may perform the requested action.

Identity or policy	Typical product use
No session	Public articles, pricing, and contact pages
Anonymous session	A trial experience before registration
Registered account	Persistent personal settings and customer resources
Verified email	Features that require a confirmed contact address
Paid plan	Subscription features and resource allowances
Resource ownership	Access to a specific document, upload, or record

Combine the policies a feature needs. For example, a paid export might require a registered customer, access to the requested document, and the appropriate subscription. A valid session alone does not answer all three questions.

The included protected calls establish identity on the server. Plan authorization adds subscription checks to an operation.

Anonymous access

Anonymous sign-in gives a visitor a real session and a customer record, making it useful for product previews and low-friction onboarding. The existing session middleware accepts that identity, so choose explicitly which actions are available before registration.

For a writing tool, you might allow a guest to try a short generation and require registration to save a library. For a file product, you might let a visitor explore a sample while reserving private uploads for registered accounts.

Within a protected server operation, a feature reserved for verified, registered customers can add this check:

if (user.isAnonymous || !user.emailVerified) {
  throw new Error("A verified account is required.");
}

Here, user is the identity already resolved by the server's session check. This adds the feature's eligibility rule; ownership and paid access still depend on the resource being requested.

Guest data

Decide what happens to guest-created data when the visitor registers, signs into an existing account, or leaves. Connect any transfer or cleanup of your own records to that lifecycle. The anonymous authentication flow does not define ownership transitions for product tables you add later.

Apply these rules on the server as well as in the interface. Hiding a button does not prevent a guest from calling its operation directly.

Customer controls

Security settings include active sessions and revocation, allowing customers to end access from another browser or device. Signing out ends the current session. Password recovery revokes existing sessions as part of the kit's configured reset policy.

Choose expiration and renewal settings around your product's needs in the Better Auth server configuration. The Better Auth session guide describes the available controls and cookie behavior without tying your documentation to a particular default duration.

For an application handling sensitive data, review session behavior alongside account settings, password recovery, and any additional verification required for destructive actions.

Private client data

The browser may hold query results from the current customer's session. When identity changes, clear customer-specific cached data and refresh session-dependent routes before showing the next customer's views.

Keep private query keys scoped to the identity and filters that determine their result. A cache is a display optimization; server authorization still applies to every fresh request. Data fetching covers the relationship between sessions and TanStack Query.

Never persist session tokens in your own public configuration or expose them in logs. Let the auth integration manage its cookies and use the trusted identity resolved by the server for ownership checks.

Verification

Check a private page after a direct reload and after client-side navigation. Then repeat a private operation with no session, with an anonymous session, and with another customer's resource identifier.

Also check an expired or revoked session in an already open tab. The interface should offer a clear sign-in path, while the server rejects the private operation. These scenarios belong alongside the feature's normal success case in your browser tests.