Configure sessions and cookies

Ce contenu n'est pas encore disponible dans votre langue.

Check the public URL and cookie settings before rolling out sign-in or SSO.

Prerequisites

A working reverse proxy and TLS configuration.
Browser developer tools and access to application logs.

Steps

1. Preserve the public HTTPS origin

Use the public HTTPS hostname for sign-in. Configure the proxy and application so requests resolve to that hostname and HTTPS scheme. Set SSL=true for an HTTPS deployment, and do not disable secure cookies to work around an incorrect proxy configuration.

The session settings are under site.session in etc/config.yaml. For a typical HTTPS OIDC deployment:

site:
  session:
    secure: true
    same_site: lax
    httponly: true

The native SAML callback supports lax or none with a secure cookie; it does not support strict. Sign in with Apple requires none with a secure cookie because of its cross-site POST callback.

3. Review session lifetime

site.session.expire_after sets the rolling session lifetime. SESSION_ABSOLUTE_TIMEOUT sets a separate bound since sign-in. Review the environment reference before changing either; disabling a bound is not needed for SSO.

Restart the affected services after changing configuration.

Verify it worked

Sign in from a private browser window. In developer tools, confirm the response sets the session cookie and subsequent requests send it to the same public hostname. Follow a complete IdP round trip and confirm a page reload remains authenticated.

Troubleshooting

Sign-in succeeds, then immediately disappears: inspect browser cookie rejection messages and the application’s secure-cookie warnings. Check the scheme seen by the app, the public hostname and SameSite behavior before changing timeout values.

The warning [Session] cookie NOT written means the app refused to write a secure cookie because it saw a non-HTTPS request. Check the proxy’s forwarded scheme and the warning’s request evidence first. For a TLS-terminating proxy that cannot forward the scheme, ASSUME_HTTPS=true normalizes downstream requests to HTTPS. Enable it only when a real TLS proxy fronts an origin that clients cannot reach directly over plain HTTP; it does not provide TLS itself.

/auth POST returns 403 while the homepage works: inspect the browser’s Origin and the public scheme/host seen by the app. Full mode has its own Origin and forwarded-IP checks, enabled independently of the shared middleware switches. A proxy chain with inconsistent client-IP headers can also trigger a rejection. Repair the proxy/header configuration rather than disabling the auth protections; see Security headers.

For user-facing session revocation and connected accounts, see Sessions and identities.