Breaking

This version does modify the database and is therefore not backwards compatible with any previous version.
If you need to downgrade vom v0.16 and above, you will only be able to do this via by applying a DB Backup.

New Features

User Expiry

It is now possible to limit the lifetime of a user.
You can set an optional expiry date and time for each user. This enables temporary access, for instance in
a support case where an external person needs access for a limited time.

Once a user has expired, a few things will happen:

• The user will not be able to log in anymore.
• As soon as the scheduler notices the expiry, it will automatically invalidate all possibly existing
  sessions and refresh tokens for this user. How often the scheduler will run can be configured with the
  SCHED_USER_EXP_MINS variable. The default is 'every 60 minutes' to have a good balance between security
  and resource usage. However, if you want this to be very strict, you can adjust this down to something like
  '5 minutes' for instance.
• If configured, expired users can be cleaned up automatically after the configured time.
  By default, expired users will not be cleaned up automatically. You can enable this feature with the
  SCHED_USER_EXP_DELETE_MINS variable.

WEBAUTHN_NO_PASSWORD_EXPIRY

With this new config variable, you can define, if users with at least one valid registered passkey will
have expiring passwords (depending on the current password policy), or not.
By default, these users do not need to renew their passwords like it is defined in the password policy.

Peer IP's for sessions -> SESSION_VALIDATE_IP

When a new session is being created, the peer / remote IP will be extracted and saved with the session
information. This peer IP can be checked with each access and the session can be rejected, if this IP
has changed, which will force the user to do a new login.

This will of course happen if a user is "on the road" and uses different wireless networks on the way,
but it prevents a session hijack and usage from another machine, if an attacker has full access to the
victims machine and even can steal the encrypted session cookie and(!) the csrf token saved inside the
local storage. This is very unlikely, since the attacker would need to have full access to the machine
anyway already, but it is just another security mechanism.

If this IP should be validated each time can be configured with the new SESSION_VALIDATE_IP variable.
By default, peer IP's will be validated and a different IP for an existing session will be rejected.

Prometheus metrics exporter

Rauthy starts up a second HTTP Server for prometheus metrics endpoint and (optional) SwaggerUI.
By default, the SwaggerUI from the Docs link in the Admin UI will not work anymore, unless you
specify the SwaggerUI via config to be publicly available. This just reduces the possible attack
surface by default.

New config variables are:

# 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

User Verification status for Passkeys

For all registered passkeys, the User Verification (UV) state is now being saved and optionally checked.
You can see the status for each device with the new fingerprint icon behind its name in the UI.

New config variable:

# 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

Passkey Only Accounts

This is the biggest new feature for this release. It allows user accounts to be "passkey only".

A passkey only account does not have a password. It works only with registered passkeys with
forced additional User Verification (UV).

Take a look at the updated documentation for further information:
Passkey Only Accounts

New E-Mail verification flow

If an already existing user decides to change the E-Mail linked to the account, a new verification
flow will be started:

• A user changes the E-Mail in the Account view.
• The E-Mail will not be updated immediately, but:
  • A verification mail will be sent to the new address with an expiring magic link.
  • After the user clicked the link in the mail, the new address will be verified.
• Once a user verifies the new E-Mail:
  • The address will finally be updated in the users profile.
  • Information E-Mails about the change will be sent to the old and the new address

EMAIL_SUB_PREFIX config variable

This new variable allows you to add an E-Mail subject prefix to each mail that Rauthy sends out.
This makes it easier for external users to identify the email, what it is about and what it is
doing, in case the name 'Rauthy' does not mean anything to them.

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

New nicely looking error page template

In a few scenarios, for instance wrong client information for the authorization code flow or
a non-existing or expired magic link, Rauthy now does not return the generic JSON error response,
but actually a translated HTML page which informs the user in a nicer looking way about the problem.
This provides a way better user experience especially for all Magic Link related requests.

Rauhty DB Version check

This is an additional internal check which compares the version of the DB during startup and
the App version of Rauthy itself. This makes it possible to have way more stable and secure
migrations between versions in the future and helps prevent user error during upgrades.

Changes

• legacy MFA app pieces and DB columns have been cleaned up
  dce148a
  423db7a
• user expiry feature
  bab6bfc
  e63d1ce
  566fff1
• WEBAUTHN_NO_PASSWORD_EXPIRY config variable
  7e16b6e
• SESSION_VALIDATE_IP config variable
  828bcd2
  26924ff
• /metrics endpoint
  085d412
• WEBAUTHN_FORCE_UV config variable
• Passkey Only Accounts
  6c2406c
• New E-Mail verification flow
  260169d
• New nicely looking error page template
  0e476ab
• Rust v1.73 update
  43f5b61
• EMAIL_SUB_PREFIX config variable
  af85839
• Rauthy DB Version check
  d2d9271
• Cleanup schedulers in HA_MODE run on leader only
  4881dd8
• Updated documentation and book
  5bbaae9
• Updated dependencies
  0f11923

Images

Postgres

ghcr.io/sebadob/rauthy@sha256:874182000202f09f4161b95929c72daf8d3a6532fa7e65b86d140e12fe82ade5

sdobedev/rauthy@sha256:874182000202f09f4161b95929c72daf8d3a6532fa7e65b86d140e12fe82ade5

SQLite

ghcr.io/sebadob/rauthy@sha256:8801d043d2d4483d747d05c6f9a1489db84bd684c8769af30681958885d374da

sdobedev/rauthy@sha256:8801d043d2d4483d747d05c6f9a1489db84bd684c8769af30681958885d374da