bazzar/config/rauthy.cfg

#####################################
############## ACCESS ###############
#####################################

# If the User Registration endpoint should be accessible by anyone.
# If not, an admin must create each new user. (default: false)
#OPEN_USER_REG=true

# If set to true, the `/userinfo` endpoint will do additional validations.
# The non-strict mode will fetch the user by id from the `sub` claim and make
# sure it still exists and is enabled. The strict validation will do additional
# database fetches and validates every possible value.
# Additionally, it will look up a possibly linked user device from the `did` claim
# and make sure it still exists. It will also extract the `client_id` the token
# has been originally issued for from the `azp` claim, fetch it and make sure it
# still exists and is enabled.
# If you don't need the extra validations, you can set this to `false` to
# save some resources, if your clients to a lot of `/userinfo` lookups.
# default: true
USERINFO_STRICT=false

# Can be used when 'OPEN_USER_REG=true' to restrict the domains
# for a registration. For instance, set it to
# 'USER_REG_DOMAIN_RESTRICTION=gmail.com' to allow only
# registrations with 'user@gmail.com' (default: '')
#USER_REG_DOMAIN_RESTRICTION=some-domain.com

# If `OPEN_USER_REG=true`, you can blacklist certain domains
# on the open registration endpoint.
# Provide the domains as a `\n` separated list.
#USER_REG_DOMAIN_BLACKLIST="
#example.com
#evil.net
#"

# If set to true, a violation inside the CSRF protection middleware based
# on Sec-* headers will block invalid requests. Usually you always want this
# enabled. You may only set it to false during the first testing phase if you
# experience any issues with an already existing Rauthy deployment.
# In future releases, it will not be possible the disable these blocks.
# default: true
#SEC_HEADER_BLOCK=true

# If set to 'true', this will validate the remote peer IP address with
# each request and compare it with the IP which was used during the initial
# session creation / login. If the IP is different, the session will be
# rejected. This is a security hardening and prevents stolen access credentials,
# for instance if an attacker might have copied the encrypted session cookie
# and the XSRF token from the local storage from a user. However, this event
# is really unlikely, since it may only happen if an attacker has direct access
# to the machine itself.
#
# If your users are using mobile networks and get new IP addresses all the time,
# this means they have to do a new login each time. This is no big deal at all with 
# Webauthn / FIDO keys anyway and should not be a reason to deactivate this feature.
#
# Caution: If you are running behind a reverse proxy which does not provide the 
# X-FORWARDED-FOR header correctly, or you have the PROXY_MODE in this config
# disabled, this feature will not work. You can validate the IPs for each session
# in the Admin UI. If these are correct, your setup is okay.
#
# (default: true)
SESSION_VALIDATE_IP=false

# By default, Rauthy will log a warning into the logs, if an active password
# reset form is being access multiple times from different hosts. You can set
# this to `true` to actually block any following request after the initial one.
# This hardens the security of the password reset form a bit more, but will
# create problems with E-Mail providers like Microsoft, which cans the customers
# E-Mails and even uses links inside, which make them unusable with this set to
# true.
# This feature works by setting an encrypted cookie to the host whichever opens
# the password reset form for the very first time. All subsequent requests either
# need to provide that cookie or would otherwise be rejected.
#PASSWORD_RESET_COOKIE_BINDING=true

# Can be set to extract the remote client peer IP from a custom header name
# instead of the default mechanisms. This is needed when you are running 
# behind a proxy which does not set the `X-REAL-IP` or `X-FORWARDED-FOR` headers
# correctly, or for instance when you proxy your requests through a CDN like
# Cloudflare, which adds custom headers in this case.
# For instance, if your requests are proxied through cloudflare, your would 
# set `CF-Connecting-IP`.
PEER_IP_HEADER_NAME="CF-Connecting-IP"

# You can enable authn/authz headers which would be added to the response
# of the `/auth/v1/oidc/forward_auth` endpoint. With  `AUTH_HEADERS_ENABLE=true`,
# the headers below will be added to authenticated requests. These could
# be used on legacy downstream applications, that don't support OIDC on
# their own.
# However, be careful when using this, since this kind of authn/authz has
# a lot of pitfalls out of the scope of Rauthy.
# default: false
AUTH_HEADERS_ENABLE=true

# Configure the header names being used for the different values.
# You can change them to your needs, if you cannot easily change your
# downstream apps.
# default: x-forwarded-user
AUTH_HEADER_USER=x-forwarded-user
# default: x-forwarded-user-roles
AUTH_HEADER_ROLES=x-forwarded-user-roles
# default: x-forwarded-user-groups
AUTH_HEADER_GROUPS=x-forwarded-user-groups
# default: x-forwarded-user-email
AUTH_HEADER_EMAIL=x-forwarded-user-email
# default: x-forwarded-user-email-verified
AUTH_HEADER_EMAIL_VERIFIED=x-forwarded-user-email-verified
# default: x-forwarded-user-family-name
AUTH_HEADER_FAMILY_NAME=x-forwarded-user-family-name
# default: x-forwarded-user-given-name
AUTH_HEADER_GIVEN_NAME=x-forwarded-user-given-name
# default: x-forwarded-user-mfa
AUTH_HEADER_MFA=x-forwarded-user-mfa

# You can set different security levels for Rauthy's cookies.
# The safest option would be 'host', but may not be desirable when
# you host an application on the same origin behind a reverse proxy.
# In this case you might want to restrict to 'secure', which will then
# take the COOKIE_PATH from below into account.
# The last option is 'danger-insecure' which really should never be used
# unless you are just testing on localhost and you are using Safari.
#COOKIE_MODE=host

# If set to 'true', Rauthy will bind the cookie to the `/auth` path.
# You may want to change this only for very specific reasons and if
# you are in such a situation, where you need this, you will know it.
# Otherwise don't change this value.
# default: true
#COOKIE_SET_PATH=true

# The "catch all" route handler on `/` will compare the request path
# against a hardcoded list of common scan targets from bots and attackers.
# If the path matches any of these targets, the IP will be blacklisted
# preemptively for the set time in minutes.
# You can disable it with setting it to `0`.
# default: 1440
#SUSPICIOUS_REQUESTS_BLACKLIST=1440

# This will emit a log with level of warning if a request to `/` has
# been made that has not been caught by any of the usual routes and
# and handlers. Apart from a request to just `/` which will end in
# a redirect to `/auth/v1`, all additional path's will be logged.
# This can help to improve the internal suspicious blocklist in the
# future.
# default: false
#SUSPICIOUS_REQUESTS_LOG=false

#####################################
############# BACKUPS ###############
#####################################

# Cron job for automatic data store backups (default: "0 0 4 * * * *")
# sec min hour day_of_month month day_of_week year
#BACKUP_TASK="0 0 4 * * * *"

# The name for the data store backups. The current timestamp
# will always be appended automatically. (default: rauthy-backup-)
#BACKUP_NAME="rauthy-backup-"

# All backups older than the specified hours will be cleaned up
# automatically (default: 720)
#BACKUP_RETENTION_LOCAL=720

# The following section will only be taken into account, when
# SQLite is used as the main database. If you use Postgres, you
# should use Postgres native tooling like for instance `pgbackrest`
# to manage your backups.
# If S3 access is configured, your SQLite backups will be encrypted
# and pushed into the configured bucket.
#S3_URL=
#S3_REGION=
#S3_PATH_STYLE=false
#S3_BUCKET=my_s3_bucket_name
#S3_ACCESS_KEY=
#S3_ACCESS_SECRET=
#S3_DANGER_ALLOW_INSECURE=false

# Restores the given backup
#
# CAUTION: Be very careful with this option - it will overwrite
# any existing database! The best way to use this option is to
# provide it as an environment variable for a single start up
# and then remove it directly after success.
#
# This only works when you are using a SQLite database!
# If you are running on Postgres, you must use Postgres-native
# tooling to handle your backups.
#
# You can either restore a local backup, or an encrypted one
# from S3 storage.
#
# For restoring from a local backup, provide the folder name
# of the backup you want to restore. Local SQLite backups are
# always in `./data/backup/rauthy-backup-TIMESTAMP/` folders.
# You only provide the backup folder name itself, in this case
# it would be `rauthy-backup-TIMESTAMP` like this:
# RESTORE_BACKUP=file:rauthy-backup-TIMESTAMP
#
# If you want to restore an encrypted backup from S3 storage,
# you must provide the object name in the configured bucket.
# For instance, let's say we have an object named
# `rauthy-0.20.0-1703243039.cryptr` in our bucket, then the
# format would be:
# RESTORE_BACKUP=s3:rauthy-0.20.0-1703243039.cryptr
#
#RESTORE_BACKUP=

#####################################
############ BOOTSTRAP ##############
#####################################

# If set, the email of the default admin will be changed
# during the initialization of an empty production database.
BOOTSTRAP_ADMIN_EMAIL=admin@localhost.de

# If set, this plain text password will be used for the
# initial admin password instead of generating a random
# password.
# BOOTSTRAP_ADMIN_PASSWORD_PLAIN="123SuperSafe"

# If set, this will take the argon2id hashed password
# during the initialization of an empty production database.
# If both BOOTSTRAP_ADMIN_PASSWORD_PLAIN and
# BOOTSTRAP_ADMIN_PASSWORD_ARGON2ID are set, the hashed version
# will always be prioritized.
#BOOTSTRAP_ADMIN_PASSWORD_ARGON2ID='$argon2id$v=19$m=32768,t=3,p=2$xr23OhOHw+pNyy3dYKZUcA$CBO4NpGvyi6gvrb5uNrnsS/z/Ew+IuS0/gVqFmLKncA'

# You can provide an API Key during the initial prod database
# bootstrap. This key must match the format and pass validation.
# You need to provide it as a base64 encoded JSON in the format:
#
# ```
# struct ApiKeyRequest {
#     /// Validation: `^[a-zA-Z0-9_-/]{2,24}$`
#     name: String,
#     /// Unix timestamp in seconds in the future (max year 2099)
#     exp: Option<i64>,
#     access: Vec<ApiKeyAccess>,
# }
#
# struct ApiKeyAccess {
#     group: AccessGroup,
#     access_rights: Vec<AccessRights>,
# }
#
# enum AccessGroup {
#     Blacklist,
#     Clients,
#     Events,
#     Generic,
#     Groups,
#     Roles,
#     Secrets,
#     Sessions,
#     Scopes,
#     UserAttributes,
#     Users,
# }
#
# #[serde(rename_all = "lowercase")]
# enum AccessRights {
#     Read,
#     Create,
#     Update,
#     Delete,
# }
# ```
#
# You can use the `api_key_example.json` from `/` as
# an example. Afterwards, just `base64 api_key_example.json | tr -d '\n'`
#BOOTSTRAP_API_KEY="ewogICJuYW1lIjogImJvb3RzdHJhcCIsCiAgImV4cCI6IDE3MzU1OTk2MDAsCiAgImFjY2VzcyI6IFsKICAgIHsKICAgICAgImdyb3VwIjogIkNsaWVudHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6IFsKICAgICAgICAicmVhZCIsCiAgICAgICAgImNyZWF0ZSIsCiAgICAgICAgInVwZGF0ZSIsCiAgICAgICAgImRlbGV0ZSIKICAgICAgXQogICAgfSwKICAgIHsKICAgICAgImdyb3VwIjogIlJvbGVzIiwKICAgICAgImFjY2Vzc19yaWdodHMiOiBbCiAgICAgICAgInJlYWQiLAogICAgICAgICJjcmVhdGUiLAogICAgICAgICJ1cGRhdGUiLAogICAgICAgICJkZWxldGUiCiAgICAgIF0KICAgIH0sCiAgICB7CiAgICAgICJncm91cCI6ICJHcm91cHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6IFsKICAgICAgICAicmVhZCIsCiAgICAgICAgImNyZWF0ZSIsCiAgICAgICAgInVwZGF0ZSIsCiAgICAgICAgImRlbGV0ZSIKICAgICAgXQogICAgfQogIF0KfQ=="

# The secret for the above defined bootstrap API Key.
# This must be at least 64 alphanumeric characters long.
# You will be able to use that key afterwards with setting
# the `Authorization` header:
#
# `Authorization: API-Key <your_key_name_from_above>$<this_secret>`
#BOOTSTRAP_API_KEY_SECRET=twUA2M7RZ8H3FyJHbti2AcMADPDCxDqUKbvi8FDnm3nYidwQx57Wfv6iaVTQynMh

#####################################
############## CACHE ################
#####################################

# If the cache should start in HA mode or standalone
# accepts 'true|false', defaults to 'false'
#HA_MODE=false

# The connection strings (with hostnames) of the HA instances
# as a CSV.
# Format: 'scheme://hostname:port'
#HA_HOSTS="http://rauthy-0.rauthy:8000, http://rauthy-1.rauthy:8000, http://rauthy-2.rauthy:8000"

# Overwrite the hostname which is used to identify each cache member.
# Useful in scenarios, where for instance all members are on the same host with
# different ports or for testing.
#HOSTNAME_OVERWRITE="rauthy-0.rauthy:8080"

## Define buffer sizes for channels between the components
# Buffer for client requests on the incoming stream - server
# side (default: 128)
# Make sense to have the CACHE_BUF_SERVER set to:
# `(number of total HA cache hosts - 1) * CACHE_BUF_CLIENT`
# In a non-HA deployment, set the same size for both
#CACHE_BUF_SERVER=128
# Buffer for client requests to remote servers for all cache
# operations (default: 128)
#CACHE_BUF_CLIENT=128

# The max cache size for users. If you can afford it memory-wise,
# make it possible to fit all active users inside the cache.
# The cache size you provide here should roughly match the
# amount of users you want to be able to cache actively. Depending
# on your setup (WebIDs, custom attributes, ...), this number
# will be multiplied internally  by 3 or 4 to create multiple cache
# entries for each user.
# default: 100
CACHE_USERS_SIZE=100
# The lifespan of the users cache in seconds. Cache eviction on
# updates will be handled automatically.
# default: 28800
CACHE_USERS_LIFESPAN=28800

# Secret token, which is used to authenticate the cache members
#CACHE_AUTH_TOKEN=SomeSuperSecretAndVerySafeToken1337

## Connections Timeouts

# The Server sends out keepalive pings with configured timeouts
# The keepalive ping interval in seconds (default: 5)
#CACHE_KEEPALIVE_INTERVAL=5
# The keepalive ping timeout in seconds (default: 5)
#CACHE_KEEPALIVE_TIMEOUT=5

# The timeout for the leader election. If a newly saved leader
# request has not reached quorum after the timeout, the leader
# will be reset and a new request will be sent out.
# CAUTION:
# This should not be lower than CACHE_RECONNECT_TIMEOUT_UPPER,
# since cold starts and elections will be problematic in that
# case.
# value in seconds, default: 15
#CACHE_ELECTION_TIMEOUT=15

# These 2 values define the reconnect timeout for the HA Cache
# Clients. The values are in ms and a random between these 2
# will be chosen each time to avoid conflicts and race conditions
# (default: 2500)
#CACHE_RECONNECT_TIMEOUT_LOWER=2500
# (default: 5000)
#CACHE_RECONNECT_TIMEOUT_UPPER=5000

#####################################
############ DATABASE ###############
#####################################

# The database driver will be chosen at runtime depending on
# the given DATABASE_URL format. Examples:
# Sqlite: 'sqlite:data/rauthy.db' or 'sqlite::memory:'
# Postgres: 'postgresql://User:PasswordWithoutSpecialCharacters@localhost:5432/DatabaseName'
#
# NOTE: The password in this case should be alphanumeric. Special
# characters could cause problems in the connection string.
#
# CAUTION:
# To make the automatic migrations work with Postgres15, when
# you do not want to just use the `postgres` user, You need
# to have a user with the same name as the DB / schema. For
# instance, the following would work without granting extra
# access to the `public` schema which is disabled by default
# since PG15:
#
# database: rauthy
# user: rauthy
# schema: rauthy with owner rauthy
#
#DATABASE_URL=sqlite::memory:
#DATABASE_URL=sqlite:data/rauthy.db
#DATABASE_URL=postgresql://rauthy:123SuperSafe@localhost:5432/rauthy

# Max DB connections - irrelevant for SQLite (default: 5)
#DATABASE_MAX_CONN=5

# If specified, the current Database, set with DATABASE_URL,
# will be DELETED and OVERWRITTEN with a migration from the
# given database with this variable. Can be used to migrate
# between different databases.
# 
# !!! USE WITH CARE !!!
#MIGRATE_DB_FROM=sqlite:data/rauthy.db

# Disables the housekeeping schedulers (default: false)
#SCHED_DISABLE=true

# The interval in minutes in which the scheduler for expired 
# users should run. If this finds expired users, it invalidates 
# all existing sessions and refresh tokens for this user.
# default: 60
#SCHED_USER_EXP_MINS=60

# The threshold in minutes after which time the user expiry 
# scheduler should automatically clean up expired users.
# If not set at all, expired users will never be cleaned up 
# automatically.
# default: disabled / not set
#SCHED_USER_EXP_DELETE_MINS=7200

#####################################
############## DPOP #################
#####################################

# May be set to 'false' to disable forcing the usage of 
# DPoP nonce's.
# default: true
DPOP_FORCE_NONCE=true

# Lifetime in seconds for DPoP nonces. These are used to 
# limit the lifetime of a client's DPoP proof. Do not set
# lower than 30 seconds to avoid too many failed client 
# token requests.
# default: 900
DPOP_NONCE_EXP=900

#####################################
########## DYNAMIC CLIENTS ##########
#####################################

# If set to `true`, dynamic client registration will be enabled.
# Only activate this, if you really need it and you know, what
# you are doing. The dynamic client registration without further
# restriction will allow anyone to register new clients, even
# bots and spammers, and this may create security issues, if not
# handled properly and your users just login blindly to any client
# they get redirected to.
# default: false
#ENABLE_DYN_CLIENT_REG=false

# If specified, this secret token will be expected during
# dynamic client registrations to be given as a
# `Bearer <DYN_CLIENT_REG_TOKEN>` token. Needs to be communicated
# in advance.
# default: <empty>
#DYN_CLIENT_REG_TOKEN=

# The default token lifetime in seconds for a dynamic client,
# that will be set during the registration.
# This value can be modified manually after registration via
# the Admin UI like for any other client.
# default: 1800
#DYN_CLIENT_DEFAULT_TOKEN_LIFETIME=1800

# If set to 'true', client secret and registration token will be
# automatically rotated each time a dynamic client updates itself
# via the PUT endpoint. This is the only way that secret rotation
# could be automated safely.
# However, this is not mandatory by RFC and it may lead to errors,
# if the dynamic clients are not implemented properly to check for
# and update their secrets after they have done a request.
# If you get into secret-problems with dynamic clients, you should
# update the client to check for new secrets, if this is under your
# control. If you cannot do anything about it, you might set this
# value to 'false' to disable secret rotation.
# default: true
#DYN_CLIENT_SECRET_AUTO_ROTATE=true

# This scheduler will be running in the background, if
# `ENABLE_DYN_CLIENT_REG=true`. It will auto-delete dynamic clients,
# that have been registered and not been used in the following
# `DYN_CLIENT_CLEANUP_THRES` hours.
# Since a dynamic client should be used right away, this should never
# be a problem with "real" clients, that are not bots or spammers.
#
# The interval is specified in minutes.
# default: 60
#DYN_CLIENT_CLEANUP_INTERVAL=60

# The threshold for newly registered dynamic clients cleanup, if
# not being used within this timeframe. This is a helper to keep
# the database clean, if you are not using any `DYN_CLIENT_REG_TOKEN`.
# The threshold should be specified in minutes. Any client, that has
# not been used within this time after the registration will be
# automatically deleted.
#
# Note: This scheduler will only run, if you have not set any
# `DYN_CLIENT_REG_TOKEN`.
#
# default: 60
#DYN_CLIENT_CLEANUP_MINUTES=60

# The rate-limiter timeout for dynamic client registration.
# This is the timeout in seconds which will prevent an IP from
# registering another dynamic client, if no `DYN_CLIENT_REG_TOKEN`
# is set. With a `DYN_CLIENT_REG_TOKEN`, the rate-limiter will not
# be applied.
# default: 60
#DYN_CLIENT_RATE_LIMIT_SEC=60

#####################################
############# E-MAIL ################
#####################################

# This contact information will be added to the `rauthy`client
# within the anti lockout rule with each new restart.
RAUTHY_ADMIN_EMAIL="admin@localhost.de"

# Will be used as the prefix for the E-Mail subject for each E-Mail 
# that will be sent out to a client.
# This can be used to further customize your deployment.
# default: "Rauthy IAM"
EMAIL_SUB_PREFIX="Rauthy IAM"

# Rauthy will force TLS and try a downgrade to STARTTLS, if
# TLS fails. It will never allow an unencrypted connection.
# You might want to set `SMTP_DANGER_INSECURE=true` if you
# need this for local dev.
#SMTP_URL=
#SMTP_USERNAME=
#SMTP_PASSWORD=
# Format: "Rauthy <rauthy@localhost.de>"
# default: "Rauthy <rauthy@localhost.de>"
#SMTP_FROM=

# The number of retries that should be done for connecting to
# the given SMTP_URL.
# When these retries are exceeded without success, Rauthy will
# panic and exit, so no E-Mail can get lost silently because of
# a missing SMTP connection.
# default: 3
#SMTP_CONNECT_RETRIES=3

# You can set this to `true` to allow an unencrypted and
# unauthenticated SMTP connection to an SMTP relay on your localhost
# or for development purposes.
# When set to `true`, `SMTP_USERNAME` and `SMTP_PASSWORD` will be
# ignored and you can modify the target port with
# `SMTP_DANGER_INSECURE_PORT`.
# default: false
#SMTP_DANGER_INSECURE=false

# The port for an insecure SMTP relay.
# This will most likely be used for testing only.
# It will only be taken into account if `SMTP_DANGER_INSECURE=true` is set.
# default: 1025
#SMTP_DANGER_INSECURE_PORT=1025

#####################################
###### ENCRYPTION / HASHING #########
#####################################

# You need to define at least one valid encryption key.
# These keys are used in various places, like for instance
# encrypting confidential client secrets in the database, or
# encryption cookies, and so on.
#
# The format must match:
ENC_KEYS="
q6u26onRvXVG4427/M0NFQzhSSldCY01rckJNa1JYZ3g2NUFtSnNOVGdoU0E=
bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=
"
#
# The first part until the first `/` is the key ID.
# The ID must match '[a-zA-Z0-9]{2,20}'
#
# The key itself begins after the first `/` has been found.
# The key must be exactly 32 bytes long, encoded as base64.
# 
# You can find a more detailed explanation on how to generate
# keys in the documentation:
# 1. https://sebadob.github.io/rauthy/getting_started/k8s.html#create-and-apply-secrets
# 2. https://sebadob.github.io/rauthy/config/encryption.html
#
# You can provide multiple keys to make things like key 
# rotation work. Be careful with removing old keys. Make sure
# that all secrets have been migrated beforehand.
# You can find a utility in the Admin UI to do this for you.
#
#ENC_KEYS="
#q6u26onRvXVG4427/M0NFQzhSSldCY01rckJNa1JYZ3g2NUFtSnNOVGdoU0E=
#bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=
#"

# This identifies the key ID from the `ENC_KEYS` list, that
# should actively be used for new encryptions.
ENC_KEY_ACTIVE=bVCyTsGaggVy5yqQ

# Argon2ID hashing parameters. Take a look at the documentation
# for more information:
# https://sebadob.github.io/rauthy/config/argon2.html
# M_COST should never be below 32768 in production
ARGON2_M_COST=131072
# T_COST should never be below 1 in production
ARGON2_T_COST=4
# P_COST should never be below 2 in production
ARGON2_P_COST=8

# Limits the maximum amount of parallel password hashes at
# the exact same time to never exceed system memory while
# still allowing a good amount of memory for the argon2id
# algorithm (default: 2)
#
# CAUTION: You must make sure, that you have at least
# (MAX_HASH_THREADS * ARGON2_M_COST / 1024) + idle memory
# of your deployment available
MAX_HASH_THREADS=1

# The time in ms when to log a warning, if a request waited
# longer than this time. This is an indicator, that you have
# more concurrent logins than allowed and may need config 
# adjustments,
# if this happens more often. (default: 500)
#HASH_AWAIT_WARN_TIME=500

# JWKS auto rotate cronjob. This will (by default) rotate 
# all JWKs every 1. day of the month. If you need smaller 
# intervals, you may adjust this value. For security reasons,
# you cannot fully disable it.
# In a HA deployment, this job will only be executed on the 
# current cache leader at that time.
# Format: "sec min hour day_of_month month day_of_week year"
# default: "0 30 3 1 * * *"
#JWK_AUTOROTATE_CRON="0 30 3 1 * * *"

#####################################
####### EPHEMERAL CLIENTS ###########
#####################################

# Can be set to 'true' to allow the dynamic client lookup via URLs as
# 'client_id's during authorization_code flow initiation.
# default: false
#ENABLE_EPHEMERAL_CLIENTS=false

# Can be set to 'true' to enable WebID functionality like needed
# for things like Solid OIDC.
# default: false
#ENABLE_WEB_ID=false

# If set to 'true', 'solid' will be added to the 'aud' claim from the ID token
# for ephemeral clients.
# default: false
#ENABLE_SOLID_AUD=false

# If set to 'true', MFA / Passkeys will be forced for ephemeral clients.
# default: false
#EPHEMERAL_CLIENTS_FORCE_MFA=false

# The allowed flows separated by ' ' for ephemeral clients.
# default: "authorization_code"
#EPHEMERAL_CLIENTS_ALLOWED_FLOWS="authorization_code refresh_token"

# The allowed scopes separated by ' ' for ephemeral clients.
# default: "openid profile email webid"
#EPHEMERAL_CLIENTS_ALLOWED_SCOPES="openid profile email webid"

# The lifetime in seconds ephemeral clients will be kept inside the cache.
# default: 3600
#EPHEMERAL_CLIENTS_CACHE_LIFETIME=3600

#####################################
######### EVENTS / AUDIT ############
#####################################

# The E-Mail address event notifications should be sent to.
EVENT_EMAIL=admin@localhost.de

# Matrix variables for event notifications.
# `EVENT_MATRIX_USER_ID` and `EVENT_MATRIX_ROOM_ID` are mandatory.
# Depending on your Matrix setup, additionally one of
# `EVENT_MATRIX_ACCESS_TOKEN` or `EVENT_MATRIX_USER_PASSWORD` is needed.
# If you log in to Matrix with User + Password, you may use `EVENT_MATRIX_USER_PASSWORD`.
# If you log in via OIDC SSO (or just want to use a session token you can revoke),
# you should provide `EVENT_MATRIX_ACCESS_TOKEN`.
# If both are given, the `EVENT_MATRIX_ACCESS_TOKEN` will be preferred.
#
# If left empty, no messages will be sent to Matrix.
# Format: `@<user_id>:<server address>`
#EVENT_MATRIX_USER_ID=
# Format: `!<random string>:<server address>`
#EVENT_MATRIX_ROOM_ID=
#EVENT_MATRIX_ACCESS_TOKEN=
#EVENT_MATRIX_USER_PASSWORD=
# Optional path to a PEM Root CA certificate file for the Matrix client.
#EVENT_MATRIX_ROOT_CA_PATH=path/to/my/root_ca_cert.pem
# May be set to disable the TLS validation for the Matrix client.
# default: false
#EVENT_MATRIX_DANGER_DISABLE_TLS_VALIDATION=false
# The default behavior is, that Rauthy will panic at startup if it cannot connect
# to a configured Matrix server. The reason is that event notifications cannot be
# dropped silently.
# However, if you use a self-hosted Matrix server which uses Rauthy as its OIDC
# provider and both instances went offline, you will have a chicken and egg problem:
# - Rauthy cannot connect to Matrix and will panic
# - Your Matrix server cannot connect to Rauthy and will panic
# To solve this issue, you can temporarily set this value to 'true' and revert
# back, after the system is online again.
# default: false
#EVENT_MATRIX_ERROR_NO_PANIC=false

# The Webhook for Slack Notifications.
# If left empty, no messages will be sent to Slack.
#EVENT_SLACK_WEBHOOK=

# The notification level for events. Works the same way as a logging level. 
# For instance: 'notice' means send out a notifications for all events with 
# the notice level or higher.
# Possible values:
# - info
# - notice
# - warning
# - critical
#
# default: 'warning'
EVENT_NOTIFY_LEVEL_EMAIL=warning
# default: 'notice'
EVENT_NOTIFY_LEVEL_MATRIX=notice
# default: 'notice'
EVENT_NOTIFY_LEVEL_SLACK=notice

# Define the level from which on events should be persisted inside the 
# database. All events with a lower level will be lost, if there is no 
# active event subscriber.
# Possible values:
# - info
# - notice
# - warning
# - critical
# default: 'info'
#EVENT_PERSIST_LEVEL=info

# Define the number of days when events should be cleaned up from the database.
# default: 31
#EVENT_CLEANUP_DAYS=31

# The level for the generated Event after a new user has been registered.
# default: info
EVENT_LEVEL_NEW_USER=info
# The level for the generated Event after a user has changed his E-Mail
# default: notice
EVENT_LEVEL_USER_EMAIL_CHANGE=notice
# The level for the generated Event after a user has reset its password
# default: notice
EVENT_LEVEL_USER_PASSWORD_RESET=notice
# The level for the generated Event after a user has been given the 
# 'rauthy_admin' role
# default: notice
EVENT_LEVEL_RAUTHY_ADMIN=notice
# The level for the generated Event after a new App version has been found
# default: notice
EVENT_LEVEL_RAUTHY_VERSION=notice
# The level for the generated Event after the JWKS has been rotated
# default: notice
EVENT_LEVEL_JWKS_ROTATE=notice
# The level for the generated Event after DB secrets have been migrated 
# to a new key
# default: notice
EVENT_LEVEL_SECRETS_MIGRATED=notice
# The level for the generated Event after a Rauthy instance has been 
# started
# default: info
EVENT_LEVEL_RAUTHY_START=info
# The level for the generated Event after a Rauthy entered a healthy 
# state (again)
# default: notice
EVENT_LEVEL_RAUTHY_HEALTHY=notice
# The level for the generated Event after a Rauthy entered an unhealthy 
#state
# default: critical
EVENT_LEVEL_RAUTHY_UNHEALTHY=critical
# The level for the generated Event after an IP has been blacklisted
# default: warning
EVENT_LEVEL_IP_BLACKLISTED=warning
# The level for the generated Event after certain amounts of false 
# logins from an IP
# default: critical
EVENT_LEVEL_FAILED_LOGINS_25=critical
# default: critical
EVENT_LEVEL_FAILED_LOGINS_20=critical
# default: warning
EVENT_LEVEL_FAILED_LOGINS_15=warning
# default: warning
EVENT_LEVEL_FAILED_LOGINS_10=warning
# default: notice
EVENT_LEVEL_FAILED_LOGINS_7=notice
# default: info
EVENT_LEVEL_FAILED_LOGIN=info

# If set to 'true', it will disable the app version checker.
# This is a scheduled task that looks up the latest version periodically
# by doing a request to the Github API to check the latest release.
# This ignores any type of prerelease and will only notify for a new stable.
# default: false
#DISABLE_APP_VERSION_CHECK=false

#####################################
############## FED CM ###############
#####################################

## CAUTION: The FedCM is highly experimental at this point!
## Do not attempt to use it in production because it is subject to change
## in the future! The spec is currently a draft and under active development.

# Set to `true` to enable the experimental FedCM.
# default: false
#EXPERIMENTAL_FED_CM_ENABLE=false

# Session lifetime for FedCM in seconds - the session can not be extended
# beyond this time and a new login will be forced.
# default: 2592000
#SESSION_LIFETIME_FED_CM=2592000

# Session timeout for FedCM in seconds
# When a new token / login is requested before this timeout hits the limit,
# the user will be authenticated without prompting for the credentials again.
# This is the value which can extend the session, until it hits its maximum
# lifetime set with _FED_CM.
# default: 259200
#SESSION_TIMEOUT_FED_CM=259200

#####################################
####### LIFETIMES / TIMEOUTS ########
#####################################

# Set the grace time in seconds for how long in seconds the
# refresh token should still be valid after usage. Keep this
# value small, but do not set it to 0 with an HA deployment
# to not get issues with small HA cache latencies.
#
# If you have an external client, which does concurrent
# requests, from which the request interceptor wants to refresh
# the token, you may have multiple hits on the endpoint and all
# of them should be valid.
#
# Caching is done on the endpoint itself, but grace time of 0
# will only be good for a single instance of rauthy.
# default: 5
#REFRESH_TOKEN_GRACE_TIME=5

# Session lifetime in seconds - the session can not be
# extended beyond this time and a new login will be forced.
# This is the session for the authorization code flow. 
# (default: 14400)
#SESSION_LIFETIME=14400

# If 'true', a 2FA / MFA check will be done with each automatic
# token generation, even with an active session, which kind of
# makes the session useless with Webauthn enabled, but provides
# maximum amount of security.
# If 'false', the user will not get an MFA prompt with an active
# session at the authorization endpoint.
# (default: false)
#SESSION_RENEW_MFA=false

# Session timeout in seconds
# When a new token / login is requested before this timeout hits
# the limit, the user will be authenticated without prompting for
# the credentials again.
# This is the value which can extend the session, until it hits
# its maximum lifetime set with SESSION_LIFETIME.
#SESSION_TIMEOUT=5400

# ML: magic link
# LT: lifetime
# Lifetime in minutes for reset password magic links (default: 30)
#ML_LT_PWD_RESET=30

# Lifetime in minutes for the first password magic link, for
# setting the initial password. (default: 4320)
#ML_LT_PWD_FIRST=4320

#####################################
############# LOGGING ###############
#####################################

# This is the log level for stdout logs
# Accepts: error, info, debug, trace (default: info)
#LOG_LEVEL=info

# This is a special config which allows the configuration of
# customized access logs. These logs will be logged with each
# request in addition to the normal LOG_LEVEL logs.
# The following values are valid:
# - Debug
#   CAUTION: The Debug setting logs every information available
#   to the middleware which includes SENSITIVE HEADERS
#   DO NOT use the Debug level in a working production environment!
# - Verbose
#   Verbose logging without headers - generates huge outputs
# - Basic
#   Logs access to all endpoints apart from the Frontend ones
#   which all js, css, ...
# - Modifying
#   Logs only requests to modifying endpoints and skips all GET
# - Off
# default: Modifying
#LOG_LEVEL_ACCESS=Basic

#####################################
################ MFA ################
#####################################

# If 'true', MFA for an account must be enabled to access the
# rauthy admin UI (default: true)
ADMIN_FORCE_MFA=false

#####################################
############## POW  #################
#####################################

# The difficulty for a Proof-of-Work (PoW).
# The default is 20, which is reasonable for modern processors.
# This is currently only used for the user registration via UI.
# The value must be between 10 and 99.
# default: 20
POW_DIFFICULTY=20

# The expiration duration in seconds for a PoW
# default: 30
POW_EXP=30

#####################################
############# SERVER ################
#####################################

# The server address to listen on. Can bind to a specific IP.
# default: 0.0.0.0
#LISTEN_ADDRESS=0.0.0.0

# The listen ports for HTTP / HTTPS, depending on the
# activated 'LISTEN_SCHEME'
# default: 8080
#LISTEN_PORT_HTTP=8080
# default: 8443
#LISTEN_PORT_HTTPS=8443

# The scheme to use locally, valid values:
# http | https | http_https (default: http_https)
LISTEN_SCHEME=http

# The Public URL of the whole deployment
# The LISTEN_SCHEME + PUB_URL must match the HTTP ORIGIN
# HEADER later on, which is especially important when running
# rauthy behind a reverse proxy. In case of a non-standard
# port (80/443), you need to add the port to the PUB_URL
PUB_URL=localhost:8301

# default value: number of available physical cores
#HTTP_WORKERS=1

# When rauthy is running behind a reverse proxy, set to true
# default: false
PROXY_MODE=false

# A `\n` separated list of trusted proxy CIDRs.
# When `PROXY_MODE=true` or `PEER_IP_HEADER_NAME` is set,
# these are mandatory to be able to extract the real client
# IP properly and safely to prevent IP header spoofing.
# All requests with a different source will be blocked.
#TRUSTED_PROXIES="
#192.168.14.0/24
#"

# To enable or disable the additional HTTP server to expose the /metrics endpoint
# default: true
# METRICS_ENABLE=true

# The IP address to listen on for the /metrics endpoint.
# You do not want to expose your metrics on a publicly reachable endpoint!
# default: 0.0.0.0
# METRICS_ADDR=0.0.0.0

# The post to listen on for the /metrics endpoint.
# You do not want to expose your metrics on a publicly reachable endpoint!
# default: 9090
# METRICS_PORT=9090

# If the Swagger UI should be served together with the /metrics route on the internal
# server. It it then reachable via:
# http://METRICS_ADDR:METRICS_PORT/docs/v1/swagger-ui/
# default: true
# SWAGGER_UI_INTERNAL=true

# If the Swagger UI should be served externally as well. This makes the link in the
# Admin UI work.
#
# CAUTION: The Swagger UI is open and does not require any login to be seen!
# Rauthy is open source, which means anyone could just download it and see on their
# own, but it may be a security concern to just expose less information.
# default: false
#SWAGGER_UI_EXTERNAL=false

# The interval in seconds in which keep-alives should be sent to SSE clients.
# Depending on your network setup, proxy timeouts, ...
# you may adjust this value to fit your needs.
# default: 30
#SSE_KEEP_ALIVE=30

#####################################
############ TEMPLATES ##############
#####################################

# You can overwrite some default email templating values here.
# If you want to modify the basic templates themselves, this is
# currently only possible with a custom build from source.
# The content however can mostly be set here.
# If the below values are not set, the default will be taken.

# New Password E-Mail
#TPL_EN_PASSWORD_NEW_SUBJECT="New Password"
#TPL_EN_PASSWORD_NEW_HEADER="New password for"
#TPL_EN_PASSWORD_NEW_TEXT=""
#TPL_EN_PASSWORD_NEW_CLICK_LINK="Click the link below to get forwarded to the password form."
#TPL_EN_PASSWORD_NEW_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_PASSWORD_NEW_EXPIRES="Link expires:"
#TPL_EN_PASSWORD_NEW_BUTTON="Set Password"
#TPL_EN_PASSWORD_NEW_FOOTER=""

#TPL_DE_PASSWORD_NEW_SUBJECT="Passwort Reset angefordert"
#TPL_DE_PASSWORD_NEW_HEADER="Passwort Reset angefordert für"
#TPL_DE_PASSWORD_NEW_TEXT=""
#TPL_DE_PASSWORD_NEW_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_PASSWORD_NEW_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_PASSWORD_NEW_EXPIRES="Link gültig bis:"
#TPL_DE_PASSWORD_NEW_BUTTON="Passwort Setzen"
#TPL_DE_PASSWORD_NEW_FOOTER=""

# Password Reset E-Mail
#TPL_EN_RESET_SUBJECT="Password Reset Request"
#TPL_EN_RESET_HEADER="Password reset request for"
#TPL_EN_RESET_TEXT=""
#TPL_EN_RESET_CLICK_LINK="Click the link below to get forwarded to the password request form."
#TPL_EN_RESET_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_RESET_EXPIRES="Link expires:"
#TPL_EN_RESET_BUTTON="Reset Password"
#TPL_EN_RESET_FOOTER=""

#TPL_DE_RESET_SUBJECT="Passwort Reset angefordert"
#TPL_DE_RESET_HEADER="Passwort Reset angefordert für"
#TPL_DE_RESET_TEXT=""
#TPL_DE_RESET_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_RESET_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_RESET_EXPIRES="Link gültig bis:"
#TPL_DE_RESET_BUTTON="Passwort Zurücksetzen"
#TPL_DE_RESET_FOOTER=""

#####################################
############### TLS #################
#####################################

## Rauthy TLS

# Overwrite the path to the TLS certificate file in PEM
# format for rauthy (default: tls/tls.crt)
#TLS_CERT=tls/tls.crt
# Overwrite the path to the TLS private key file in PEM
# format for rauthy. If the path / filename ends with
# '.der', rauthy will parse it as DER, otherwise as PEM.
# (default: tls/tls.key)
#TLS_KEY=tls/tls.key

## CACHE TLS

# Enable / disable TLS for the cache communication
# (default: true)
CACHE_TLS=true

# The path to the server TLS certificate PEM file
# default: tls/redhac.cert-chain.pem
CACHE_TLS_SERVER_CERT=tls/cert-chain.pem
# The path to the server TLS key PEM file
# default: tls/redhac.key.pem
CACHE_TLS_SERVER_KEY=tls/key.pem

# The path to the client mTLS certificate PEM file. This is optional.
#CACHE_TLS_CLIENT_CERT=tls/cert-chain.pem
# The path to the client mTLS key PEM file. This is optional.
#CACHE_TLS_CLIENT_KEY=tls/key.pem

# If not empty, the PEM file from the specified location will be
# added as the CA certificate chain for validating
# the servers TLS certificate. This is optional.
#CACHE_TLS_CA_SERVER=tls/ca-chain.pem
# If not empty, the PEM file from the specified location will
# be added as the CA certificate chain for validating
# the clients mTLS certificate. This is optional.
#CACHE_TLS_CA_CLIENT=tls/ca-chain.pem

# The domain / CN the client should validate the certificate
# against. This domain MUST be inside the
# 'X509v3 Subject Alternative Name' when you take a look at
# the servers certificate with the openssl tool.
# default: redhac.local
CACHE_TLS_CLIENT_VALIDATE_DOMAIN=redhac.local

# Can be used if you need to overwrite the SNI when the
# client connects to the server, for instance if you are
# behind a loadbalancer which combines multiple certificates.
# default: ""
#CACHE_TLS_SNI_OVERWRITE=

#####################################
############# WEBAUTHN ##############
#####################################

# The 'Relaying Party (RP) ID' - effective domain name
# (default: localhost)
# CAUTION: When this changes, already registered devices will stop
# working and users cannot log in anymore!
RP_ID=localhost

# Url containing the effective domain name
# (default: http://localhost:8080)
# CAUTION: Must include the port number!
RP_ORIGIN=http://localhost:8080

# Non critical RP Name
# Has no security properties and may be changed without issues
# (default: Rauthy Webauthn)
RP_NAME='Rauthy Webauthn'

# The Cache lifetime in seconds for Webauthn requests. Within
# this time, a webauthn request must have been validated.
# (default: 60)
#WEBAUTHN_REQ_EXP=60

# The Cache lifetime for additional Webauthn Data like auth
# codes and so on. Should not be lower than WEBAUTHN_REQ_EXP.
# The value is in seconds (default: 90)
#WEBAUTHN_DATA_EXP=90

# With webauthn enabled for a user, he needs to enter
# username / password on a new system. If these credentials are
# verified, rauthy will set an additional cookie, which will
# determine how long the user can then use only (safe) MFA
# passwordless webauthn login with yubikeys, apple touch id,
# Windows hello, ... until he needs to verify his credentials
# again.
# Passwordless login is generally much safer than logging in
# with a password. But sometimes it is possible, that the
# Webauthn devices do not force the user to include a second
# factor, which in that case would be a single factor login
# again. That is why we should ask for the original password
# in addition once in a while to set the cookie.
# The value is in hours (default: 2160)
WEBAUTHN_RENEW_EXP=2160

# This feature can be set to 'true' to force User verification
# during the Webauthn ceremony. UV will be true, if the user
# does not only need to verify its presence by touching the key,
# but by also providing proof that he knows (or is) some secret
# via a PIN or biometric key for instance. With UV, we have a
# true MFA scenario where UV == false (user presence only)
# would be a 2FA scenario (with password). Be careful with this
# option, since Android and some special combinations of OS +
# browser to not support UV yet.
# (default: false)
WEBAUTHN_FORCE_UV=false

# Can be set to 'true' to disable password expiry for users
# that have at least one active passkey. When set to 'false',
# the same password expiry from the set policy will apply to
# these users as well.
# With this option active, rauthy will ignore any password
# expiry set by the password policy for Webauthn users.
# default: true
#WEBAUTHN_NO_PASSWORD_EXPIRY=true