rauthy.cfg

#####################################
######## LOCAL DEVELOPMENT ##########
#####################################

# If 'true', the data store will be initialized with DEV values.
# The default password for 'admin@localhost.de' is '123SuperSafe'
# default: false
# !!! DO NOT USE IN PRODUCTION !!!
DEV_MODE=true

# This will replace the redirect port for the auth provider
# callback URI to make the login flow work, when the UI is running
# in dev mode. Without this set, the redirect URI will always be
# Rauthys PUB_URL, which does only work when the UI is being served
# with SSR.
# You only need this value, if you want to work with the auth
# provider login while running the UI in dev mode. Point it to the
#full address, where ever your UI is running.
# This will only be respected when `DEV_MODE == true` as well.
#DEV_MODE_PROVIDER_CALLBACK_URL="localhost:5173"

# Can be set to 'true' during local development to allow an HTTP scheme for the DPoP 'htu' claim
# Will only be applied if `DEV_MODE == true` as well.
# !!! DO NOT USE IN PRODUCTION !!!
DEV_DPOP_HTTP=true

# Can be set to `true` during local dev and testing to issue
# insecure cookies
# default: false
HQL_INSECURE_COOKIE=true

#####################################
############## 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=true

# Can be set to `true` to disable authorization on `/oidc/introspect`.
# This should usually never be done, but since the auth on that endpoint is not
# really standardized, you may run into issues with your client app.
# If so, please open an issue about it.
# default: false
#DANGER_DISABLE_INTROSPECT_AUTH=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-mail-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`, any validation of the `redirect_uri` provided during
# a user registration will be disabled.
# Clients can use this feature to redirect the user back to their application
# after a successful registration, so instead of ending up in the user
# dashboard, they come back to the client app that initiated the registration.
#
# The given `redirect_uri` will be compared against all registered
# `client_uri`s and will throw an error, if there is no match. However,
# this check will prevent ephemeral clients from using this feature. Only
# if you need it in combination with ephemeral clients, you should
# set this option to `true`. Otherwise it is advised to set the correct
# Client URI in the admin UI. The `redirect_uri` will be allowed if it starts
# with any registered `client_uri`.
#
# default: false
#USER_REG_OPEN_REDIRECT=true

# 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=true

# 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=danger-insecure

# 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=true

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

# When the auto-backup task should run.
# Accepts cron syntax:
# "sec min hour day_of_month month day_of_week year"
# default: "0 30 2 * * * *"
HQL_BACKUP_CRON="0 30 2 * * * *"

# Local backups older than the configured days will be cleaned up after
# the backup cron job.
# default: 30
HQL_BACKUP_KEEP_DAYS=30

# If you ever need to restore from a backup, the process is simple.
# 1. Have the cluster shut down. This is probably the case anyway, if
#    you need to restore from a backup.
# 2. Provide the backup file name on S3 storage with the
#    HQL_BACKUP_RESTORE value.
# 3. Start up the cluster again.
# 4. After the restart, make sure to remove the HQL_BACKUP_RESTORE
#    env value.
#HQL_BACKUP_RESTORE=

# Access values for the S3 bucket where backups will be pushed to.
#HQL_S3_URL=https://s3.example.com
#HQL_S3_BUCKET=my_bucket
#HQL_S3_REGION=example
#HQL_S3_KEY=s3_key
#HQL_S3_SECRET=s3_secret

# TODO remove this section after the Hiqlite migration has been finished

# 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 * * * *"
BACKUP_TASK="0 4 12 * * * *"

# 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=24

# 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=true
#S3_BUCKET=
#S3_ACCESS_KEY=
#S3_ACCESS_SECRET=
#S3_DANGER_ALLOW_INSECURE=true

# 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=file:rauthy-backup-1703243039
#RESTORE_BACKUP=s3:rauthy-0.20.0-20231220-1703243039.cryptr

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

# If set, the email of the default admin will be changed
# during the initialization of an empty production database.
#BOOTSTRAP_ADMIN_EMAIL="alfred@batcave.io"

# 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$mK+3taI5mnA+Gx8OjjKn5Q$XsOmyvt9fr0V7Dghhv3D0aTe/FjF36BfNS5QlxOPep0'

# 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 ################
#####################################

# Secrets for Raft internal authentication as well as for the API.
# These must be at least 16 characters long and you should provide
# different ones for both variables.
HQL_SECRET_RAFT=SuperSecureSecret1337
HQL_SECRET_API=SuperSecureSecret1337

# You can either parse `ENC_KEYS` and `ENC_KEY_ACTIVE` from the
# environment with setting this value to `env`, or parse them from
# a file on disk with `file:path/to/enc/keys/file`
# default: env
#HQL_ENC_KEYS_FROM=env

#####################################
############# CLUSTER################
#####################################

# Can be set to 'k8s' to try to split off the node id from the hostname
# when Hiqlite is running as a StatefulSet inside Kubernetes.
#HQL_NODE_ID_FROM=k8s

# The node id must exist in the nodes and there must always be
# at least a node with ID 1
# Will be ignored if `HQL_NODE_ID_FROM=k8s`
HQL_NODE_ID=1

# All cluster member nodes.
# To make setting the env var easy, the values are separated by `\s`
# while nodes are separated by `\n`
# in the following format:
#
# id addr_raft addr_api
# id addr_raft addr_api
# id addr_raft addr_api
#
# 2 nodes must be separated by 2 `\n`
HQL_NODES="
1 localhost:8100 localhost:8200
"

# Sets the limit when the Raft will trigger the creation of a new
# state machine snapshot and purge all logs that are included in
# the snapshot.
# Higher values can achieve more throughput in very write heavy
# situations but will end up in more disk usage and longer
# snapshot creations / log purges.
# default: 10000
#HQL_LOGS_UNTIL_SNAPSHOT=10000

#####################################
############ 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 currently configured Database 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
#MIGRATE_DB_FROM=postgresql://postgres:123SuperSafe@localhost:5432/rauthy

# TODO: make the DB url uniform after Hiqlite migration has been finished
#       -> DATABASE_URL must be valid for the sqlx macros to not panic
#
# To use the EXPERIMENTAL Hiqlite database, set to `true`
# default: false
HIQLITE=true

# The data dir hiqlite will store raft logs and state machine data in.
# default: data
#HQL_DATA_DIR=my_hiqlite

# The file name of the SQLite database in the state machine folder.
# default: hiqlite.db
#HQL_FILENAME_DB=my_hiqlite.db

# If set to `true`, all SQL statements will be logged for debugging
# purposes.
# default: false
HQL_LOG_STATEMENTS=true

# The password for the Hiqlite dashboard as Argon2ID hash.
# '123SuperMegaSafe' in this example
HQL_PASSWORD_DASHBOARD=JGFyZ29uMmlkJHY9MTkkbT0xOTQ1Nix0PTIscD0xJGQ2RlJDYTBtaS9OUnkvL1RubmZNa0EkVzJMeTQrc1dxZ0FGd0RyQjBZKy9iWjBQUlZlOTdUMURwQkk5QUoxeW1wRQ==

# If you ever need to restore from a backup, the process is simple.
# 1. Have the cluster shut down. This is probably the case anyway, if
#    you need to restore from a backup.
# 2. Provide the backup file name on S3 storage with the
#    HQL_BACKUP_RESTORE value.
# 3. Start up the cluster again.
# 4. After the restart, make sure to remove the HQL_BACKUP_RESTORE
#    env value.
#HQL_BACKUP_RESTORE=

# Defines the time in seconds after which the `/health` endpoint
# includes HA quorum checks. The initial delay solves problems
# like Kubernetes StatefulSet starts that include the health
# endpoint in the scheduling routine. In these cases, the scheduler
# will not start other Pods if the first does not become healthy.
#
# This is a chicken-and-egg problem which the delay solves.
# There is usually no need to adjust this value.
#
# default: 30
#HEALTH_CHECK_DELAY_SECS=30

# 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=5

# 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

#####################################
######### DEVICE GRANT ##############
#####################################

# The lifetime in secods  of auth codes for the Device Authorization
# Grant flow. You may increase the default of 300 seconds, if you have
# "slow users" and they are simply not fast enough with the verification.
# default: 300
DEVICE_GRANT_CODE_LIFETIME=300

# The length of the `user_code` the user has to enter manually for
# auth request validation. This must be < 64 characters.
# default: 8
DEVICE_GRANT_USER_CODE_LENGTH=8

# Specifies the rate-limit in seconds per IP for starting new Device
# Authorization Grant flows. This is especially important for public
# clients, because a code request for this flow will actually create
# cached data. If this would happen on an unrestricted, open endpoint,
# the application could easily be DoS'ed.
# If you use the `device_code` grant with confidential clients only,
# you can leave this unset, which will not rate-limit the endpoint.
# default: not set
DEVICE_GRANT_RATE_LIMIT=1

# The interval in seconds which devices are told to use when they
# poll the token endpoint during Device Authorization Grant flow.
# default: 5
DEVICE_GRANT_POLL_INTERVAL=5

# You can define a global lifetime in hours for refresh tokens issued
# from a Device Authorization Grant flow. You might want to have a
# higher lifetime than normal refresh tokens, because they might be
# used in IoT devices which may be offline for longer periods of time.
# default: 72
DEVICE_GRANT_REFRESH_TOKEN_LIFETIME=72

#####################################
############## 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=true

# 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="123SuperSafe"

# 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=localhost
#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=true

# 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
#
# CAUTION: You must make sure, that you have at least
# (MAX_HASH_THREADS * ARGON2_M_COST / 1024) + idle memory of your deployment available.
# default: 2
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=true

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

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

# 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 not 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=
# URL of your Matrix server.
# default: https://matrix.org
#EVENT_MATRIX_SERVER_URL=https://matrix.org
# Optional path to a PEM Root CA certificate file for the Matrix client.
#EVENT_MATRIX_ROOT_CA_PATH=tls/root.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=true

# 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

# Global default lifetime in hours for refresh tokens.
# default: 48
REFRESH_TOKEN_LIFETIME=48

# 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=43200

# 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 a MFA prompt with an active session at the authorization endpoint.
# (default: false)
SESSION_RENEW_MFA=true

# 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=debug

# The log level for the `Hiqlite` persistence layer.
# At the time of writing, only the cache will use `hiqlite`
# default: info
LOG_LEVEL_DATABASE=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

# You can change the log output format to JSON, if you set:
# `LOG_FMT=json`.
# Keep in mind, that some logs will include escaped values,
# for instance when `Text` already logs a JSON in debug level.
# Some other logs like an Event for instance will be formatted
# as Text anyway. If you need to auto-parse events, please consider
# using an API token and listen ot them actively.
# default: text
#LOG_FMT=json

#####################################
################ 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)
# When LISTEN_SCHEME is set to use UNIX sockets, this specifies the path to listen on.
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 | unix_http | unix_https
# For more details about the UNIX domain socket, check out its documentation page.
# default: http_https
LISTEN_SCHEME=http_https

# 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:8443

# 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 bring support for applications using deep-linking, you can set custom URL
# schemes to be accepted when present in the `Origin` header. For instance, a
# Tauri app would set `tauri://` instead of `https://`.
#
# Provide the value as a space separated list of Strings, like for instance:
# "tauri myapp"
ADDITIONAL_ALLOWED_ORIGIN_SCHEMES="tauri myapp"

# 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=true

# 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

# Dynamic server side pagination threshold
# If the total users count exceeds this value, Rauthy will dynamically
# change search and pagination for users in the Admin UI from client
# side to server side to not have a degradation in performance.
# default: 1000
SSP_THRESHOLD=1000

#####################################
############ 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/cert-chain.pem
# 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/key.pem

## CACHE TLS

# If given, these keys / certificates will be used to establish
# TLS connections between nodes.
HQL_TLS_RAFT_KEY=tls/key.pem
HQL_TLS_RAFT_CERT=tls/cert-chain.pem
HQL_TLS_RAFT_DANGER_TLS_NO_VERIFY=true

HQL_TLS_API_KEY=tls/key.pem
HQL_TLS_API_CERT=tls/cert-chain.pem
HQL_TLS_API_DANGER_TLS_NO_VERIFY=true

#####################################
############# 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)
# If you want to test Webauthn via the Svelte DEV UI, change the port number to :5173.
# CAUTION: Must include the port number!
RP_ORIGIN=http://localhost:8080
#RP_ORIGIN=http://localhost:5173

# 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=true

# 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