new·Earn with mozg — 20% of every monthSend somebody here and take a fifth of every plan payment they make, for as long as they keep paying — not a bounty on the first invoice. Your handle is the link, the window is thirty days, and the commission lands on your balance the second they pay. Free to join: if you have signed in, you already have the link. mozg.sh/earnall news →
mozg.beta
Sign in

Better Auth · all subjects

session & cookie management

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

session configuration options

The session option accepts: modelName (model name for session; default: "sessions"), fields (map fields to different column names), expiresIn (session token expiration in seconds; default: 604800 / 7 days), updateAge (session refresh interval in seconds; default: 86400 / 1 day), disableSessionRefresh (disable session refresh so session is not updated regardless of updateAge; default: false), additionalFields (additional fields for session table with type specifications), storeSessionInDatabase (store session in database when secondary storage is provided; default: false), preserveSessionInDatabase (preserve session records in database when deleted from secondary storage; default: false), and cookieCache (object with enabled boolean, maxAge in seconds, and strategy: "jwt").

storeAccountCookie behavior and limitations

When storeAccountCookie is enabled, the account cookie has a five-minute max age and is refreshed when Better Auth writes updated provider account data (after getAccessToken or /refresh-token refresh). When refreshed in server-side code, forward the returned Set-Cookie header to the browser to retain the refreshed cookie. Pass useAccountCookie: true to getAccessToken, refreshToken, or accountInfo when the signed cookie should select the account; these APIs require an explicit accountId or useAccountCookie: true. Better Auth chunks oversized account cookies, but browsers and proxies can enforce total cookie or header limits, so prefer database-backed account storage for providers issuing large JWTs or production flows needing durable token storage. Read decrypted account cookie in hooks/middleware using getAccountCookie from better-auth/cookies.

advanced.cookies configuration

The advanced.cookies option allows customizing cookie names and attributes. It accepts an object where each key is a cookie name (like "session_token") and the value is an object with name property (custom cookie name) and attributes object (httpOnly, secure, etc.).

advanced.crossSubDomainCookies configuration

The advanced.crossSubDomainCookies option configures cookies to be shared across subdomains. It accepts: enabled (boolean), additionalCookies (array of additional cookie names), and domain (explicit cookie domain). When enabled and domain is not set explicitly, cookie domain is derived from the resolved request host.

advanced.useSecureCookies option

The advanced.useSecureCookies option forces the Secure cookie attribute in all environments when set to true. By default, cookies are secure only in production environments.

advanced.cookiePrefix configuration

The advanced.cookiePrefix option adds a prefix to all cookies generated by Better Auth. For example, setting it to "myapp" prefixes cookie names with "myapp".

advanced.defaultCookieAttributes configuration

The advanced.defaultCookieAttributes option sets default attributes applied to all cookies. It accepts an object with properties like httpOnly (boolean) and secure (boolean).

Give your agent this brain