Cookies

Better Auth uses HTTP cookies to persist session tokens in the browser. This page explains how cookies are configured and the security implications of each setting.

By default, Better Auth sets session cookies with the following attributes:

Attribute	Default	Description
Name	`better-auth.session_token`	Cookie name
Path	`/`	Available on all paths
Secure	Derived from `base_url`	Enabled for HTTPS, disabled for HTTP
HttpOnly	`true`	Not accessible via JavaScript
SameSite	`Lax`	CSRF protection with top-level navigation support

Configuration

Configure cookie behavior through AuthConfig:

use better_auth::AuthConfig;
use better_auth::config::SameSite;
use chrono::Duration;

let mut config = AuthConfig::new("your-secret-key-at-least-32-chars");
config.session.cookie_name = "my-app.session".to_string();
config.session.cookie_secure = true;
config.session.cookie_http_only = true;
config.session.cookie_same_site = SameSite::Lax;
config.session.expires_in = Duration::hours(24 * 7); // 7 days

Secure

When true, the cookie is only sent over HTTPS connections. This prevents session tokens from being transmitted in plaintext.

config.session.cookie_secure = true;

Always set Secure: true in production. Only disable it for local development over HTTP.

HttpOnly

When true, the cookie cannot be accessed by JavaScript (document.cookie). This prevents XSS attacks from stealing session tokens.

config.session.cookie_http_only = true;

Always keep this enabled unless you have a specific reason to access the session token from JavaScript.

SameSite

Controls when the cookie is sent with cross-site requests:

Value	Behavior
`Strict`	Cookie only sent for same-site requests. Most secure but may break OAuth redirects.
`Lax`	Cookie sent for same-site requests and top-level navigations (GET only). Recommended default.
`None`	Cookie sent for all requests. Requires `Secure: true`. Use for cross-origin API access.

use better_auth::config::SameSite;

// Recommended for most applications
config.session.cookie_same_site = SameSite::Lax;

// For cross-origin API access (requires Secure: true)
config.session.cookie_same_site = SameSite::None;

Expiration

The cookie expiration matches the session expiration time. When a session is created, the Expires attribute is set accordingly.

use chrono::Duration;

// Session and cookie expire after 7 days
config.session.expires_in = Duration::hours(24 * 7);

The session cookie is set via the Set-Cookie HTTP header:

Set-Cookie: better-auth.session_token=session_abc123.signature; Path=/; Expires=Thu, 08 Jan 2025 00:00:00 GMT; Secure; HttpOnly; SameSite=Lax

Cross-Origin Usage

If your frontend and backend are on different origins, you need to:

Set SameSite::None and Secure: true on the cookie
Configure CORS to allow credentials:

This example assumes you've already defined AppAuthSchema. If you want a complete setup from entity definitions through Axum mounting, start with the Axum integration guide.

use better_auth::CorsConfig;

let auth = BetterAuth::<AppAuthSchema>::new(config)
    .cors(
        CorsConfig::new()
            .allowed_origin("https://frontend.example.com")
            .allow_credentials(true)
    )
    .build()
    .await?;

Include credentials in frontend requests:

fetch('https://api.example.com/auth/get-session', {
  credentials: 'include' // Send cookies cross-origin
});

Alternative: Bearer Token

Enable Bearer transport for mobile apps or API clients:

use better_auth::config::BearerConfig;

config.session.bearer = Some(BearerConfig::default());

Then send the raw token returned by sign-in or the signed token returned in set-auth-token:

Authorization: Bearer session_abc123...

A valid Bearer token takes precedence over the signed session cookie. Set BearerConfig { require_signature: true } to require a signed Bearer token. Without Bearer configuration, session authentication uses the signed cookie.

Optional cookie caching stores signed or encrypted session data in better-auth.session_data. The cache requires the matching session-token cookie.