Skip to main content

Production Checklist

Security​

  • TLS everywhere — Autentico is behind a reverse proxy with a valid TLS certificate. AUTENTICO_APP_URL starts with https://.
  • Strong secrets — AUTENTICO_CSRF_SECRET_KEY, AUTENTICO_ACCESS_TOKEN_SECRET, and AUTENTICO_REFRESH_TOKEN_SECRET are all strong, unique hex strings (generated by autentico init).
  • Persistent RSA key — AUTENTICO_PRIVATE_KEY is set to a stable base64-encoded PEM value (generated by autentico init). If it's not set, an ephemeral key is used and all tokens are invalidated on restart.
  • Private key backup — The value of AUTENTICO_PRIVATE_KEY is backed up securely (e.g., in a secrets manager). Losing it invalidates all issued tokens.
  • Secrets in secrets manager — AUTENTICO_PRIVATE_KEY, AUTENTICO_ACCESS_TOKEN_SECRET, AUTENTICO_REFRESH_TOKEN_SECRET, and AUTENTICO_CSRF_SECRET_KEY are not committed to source control or exposed in logs.
  • Database backup — The SQLite database is backed up regularly. Consider a cron job using sqlite3 /data/autentico.db ".backup /backups/autentico-$(date +%Y%m%d).db".

Configuration​

  • AUTENTICO_APP_URL is correct — This value appears in the OIDC discovery document, token iss claim, and redirect validation. It must exactly match the URL clients use.
  • MFA enabled (recommended) — require_mfa = true in settings, with mfa_method = totp or email. TOTP is preferred.
  • Account lockout configured — account_lockout_max_attempts and account_lockout_duration are set to reasonable values.
  • Session lifetimes reviewed — sso_session_idle_timeout and sso_session_max_age match your security policy.
  • Token lifetimes reviewed — access_token_expiration is short (15m default). refresh_token_expiration reflects your session policy.
  • Self-signup decision made — allow_self_signup is false unless you intend to allow open registration.
  • SMTP configured (if using email OTP or email-verified registration) — SMTP settings tested via a login attempt.

Operations​

  • Cleanup job running — Background cleanup is active (it starts automatically). Check logs to confirm [cleanup] entries appear.
  • Log aggregation — Autentico logs to stdout. Forward logs to your SIEM or log management system.
  • Alerting — Alert on repeated failed login attempts, admin API errors, and server startup failures.
  • Health check — Monitor GET /healthz — the dedicated lightweight health check endpoint. GET /.well-known/openid-configuration also returns 200 when the server is healthy, but /healthz is faster and purpose-built for monitoring.
  • Upgrade tested — You have tested the upgrade path (pull new image, restart) in a non-production environment.

Clients​

  • Only necessary grant types enabled — Each registered client has only the grant types it actually uses.
  • Redirect URIs are exact — No wildcards. Each redirect URI is the precise URL the client will use.
  • Confidential clients have secrets — Server-side apps are registered as confidential with client_secret_basic or client_secret_post.
  • Public clients use PKCE — Browser and mobile apps are registered as public with none auth method and must use PKCE.
tip

After launch, revisit the Admin UI Sessions page periodically to look for anomalous session patterns (many sessions from unexpected IPs, unusual user agents, etc.).