v0.20.0

Breaking

This update is not backwards-compatible with any previous version. It will modify the database under the hood
which makes it incompatible with any previous version. If you need to downgrade for whatever reason, you will
only be able to do this by applying a database backup from an older version.
Testing has been done and everything was fine in tests. However, if you are using Rauthy in production, I recommend
taking a database backup, since any version <= v0.19 will not be working with a v0.20+ database.

IMPORTANT Upgrade Notes

If you are upgrading from any earlier version, there is a manual action you need to perform, before you can
start v0.20.0. If this has not been done, it will simply panic early and not start up. Nothing will get damaged.

The internal encryption of certain values has been changed. Rauthy now uses cryptr to handle these things,
like mentioned below as well.

However, to make working with encryption keys easier and provide higher entropy, the format has changed.
You need to convert your currently used ENC_KEYS to the new format:

Option 1: Use cryptr CLI

1. Install cryptr - https://github.com/sebadob/cryptr

If you have Rust available on your system, just execute:

cargo install cryptr --features cli --locked

Otherwise, pre-built binaries do exist:

Linux: https://github.com/sebadob/cryptr/raw/main/out/cryptr_0.2.2

Windows: https://github.com/sebadob/cryptr/raw/main/out/cryptr_0.2.2.exe

2. Execute:

cryptr keys convert legacy-string

3. Paste your current ENC_KEYS into the command line.

For instance, if you have

ENC_KEYS="bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA"

in your config, paste

bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA

If you provide your ENC_KEYS via a Kubernetes secret, you need to do a base64 decode first.
For instance, if your secret looks something like this

ENC_KEYS: YlZDeVRzR2FnZ1Z5NXlxUS9TOW43b0NlbjUzeFNKTHpjc21mZG5CRHZOcnFRNjNyNCBxNnUyNm9uUnZYVkc0NDI3LzNDRUM4UkpXQmNNa3JCTWtSWGd4NjVBbUpzTlRnaFNB

Then decode via shell or any tool your like:

echo -n YlZDeVRzR2FnZ1Z5NXlxUS9TOW43b0NlbjUzeFNKTHpjc21mZG5CRHZOcnFRNjNyNCBxNnUyNm9uUnZYVkc0NDI3LzNDRUM4UkpXQmNNa3JCTWtSWGd4NjVBbUpzTlRnaFNB | base64 -d

... and paste the decoded value into cryptr

4. cryptr will output the correct format for either usage in config or as kubernetes secret again

5. Paste the new format into your Rauthy config / secret and restart.

Option 2: Manual

Rauthy expects the ENC_KEYS now base64 encoded, and instead of separated by whitespace it expects them to
be separated by \n instead.
If you don't want to use cryptr you need to convert your current keys manually.

For instance, if you have

ENC_KEYS="bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA"

in your config, you need to convert the enc key itself, the value after the /, to base64, and then separate
them with \n.

For instance, to convert bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4, split off the enc key part
S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 and encode it with base64:

echo -n 'S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4' | base64

Then combine the result with the key id again to:

bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=

Do this for every key you have. The ENC_KEYS should then look like this in the end:

ENC_KEYS="
bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=
q6u26onRvXVG4427/M0NFQzhSSldCY01rckJNa1JYZ3g2NUFtSnNOVGdoU0E=
"

Important:
Make sure to not add any newline characters or spaces when copying values around when doing the bas64 encoding!

Encrypted SQLite backups to S3 storage

Rauthy can now push encrypted SQLite backups to a configured S3 bucket.
The local backups to data/backups/ do still exist. If configured, Rauthy will now push backups from SQLite
to an S3 storage and encrypt them on the fly. All this happens with the help of cryptr
which is a new crate of mine. Resource usage is minimal, even if the SQLite file would be multiple GB's big.
The whole operation is done with streaming.

Auto-Restore SQLite backups

Rauthy can now automatically restore SQLite backups either from a backup inside data/backups/ locally, or
fetch an encrypted backup from an S3 bucket. You only need to set the new RESTORE_BACKUP environment variable
at startup and Rauthy will do the rest. No manually copying files around.
For instance, a local backup can be restored with setting RESTORE_BACKUP=file:rauthy-backup-1703243039 and an
S3 backup with RESTORE_BACKUP=s3:rauthy-0.20.0-1703243039.cryptr.

Test S3 config at startup

To not show unexpected behavior at runtime, Rauthy will initialize and test a configured S3 connection
at startup. If anything is not configured correctly, it will panic early. This way, when Rauthy starts
and the tests are successful, you know it will be working during the backup process at night as well, and
it will not crash and throw errors all night long, if you just had a typo somewhere.

Migration to spow

The old (very naive) Proof-of-Work (PoW) mechanism for bot and spam protection has been migrated to make use
of the spow crate, which is another new project of mine.
With this implementation, the difficulty for PoW's a client must solve can be scaled up almost infinitely,
while the time is takes to verify a PoW on the server side will always be O(1), no matter hoch high the
difficulty was. spow uses a modified version of the popular Hashcat PoW algorithm, which is also being used
in the Bitcoin blockchain.

Separate users cache

A typical Rauthy deployment will have a finite amount of clients, roles, groups, scopes, and so on.
The only thing that might scale endlessly are the users. Because of this, the users are now being cached
inside their own separate cache, which can be configured and customized to fit the deployment's needs.
You can now set the upper limit and the lifespan for cached user's. This is one of the first upcoming
optimizations, since Rauthy gets closer to the first v1.0.0 release:

E-Mails as lowercase only

Up until now, it was possible to register the same E-Mail address multiple times with using uppercase characters.
E-Mail is case-insensitive by definition though. This version does a migration of all currently existing E-Mail addresses
in the database to lowercase only characters. From that point on, it will always convert any address to lowercase only
characters to avoid confusion and conflicts.
This means, if you currently have the same address in your database with different casing, you need to resolve this
issue manually. The migration function will throw an error in the console at startup, if it finds such a conflict.

# 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

Additional claims available in ID tokens

The scope profile now additionally adds the following claims to the ID token (if they exist for the user):

• locale
• birthdate

The new scope address adds:

• address in JSON format

  The new scope phone adds:

• phone

Changes

• new POST /events API endpoint which serves archived events
  d5d4b01
• new admin UI section to fetch and filter archived events.
  ece73bb
• backend + frontend dependencies have been updated to the latest versions everywhere
• The internal encryption handling has been changed to a new project of mine called cryptr.
  This makes the whole value encryption way easier, more stable and future-proof, because values have their own
  tiny header data with the minimal amount of information needed. It not only simplifies encryption key rotations,
  but also even encryption algorithm encryptions really easy in the future.
  d6c224e
  c3df3ce
• Push encrypted SQLite backups to S3 storage
  fa0e496
• S3 connection and config test at startup
  701c785
• Auto-Restore SQLite backups either from file or S3
  65bbfea
• Migrate to spow
  ff579f6
• Pre-Compute CSP's for all HTML content at build-time and get rid of the per-request nonce computation
  8fd2c99
• noindex, nofollow globally via heade...

v0.19.2

Changes

• Invalidate all user sessions after a password reset to have a more uniform flow and better UX
  570dea6
• Add an additional foreign key constraint on the user_attr_values table to cascade rows
  on user deletion for enhanced stability during user deletions
  1dc730c

Bugfixes

• Fix a bug when an existing user with already registered passkeys would not be able
  to use the password reset functionality correctly when opened in a fully fresh browser
  24af03c
• Fix cache evictions of existing user sessions after a user has been deleted while having
  an active session
  ed76418
• Fix some default values in the reference config docs not having the correct default documented
  a7101b2

Images

Postgres

ghcr.io/sebadob/rauthy:0.19.2

SQLite

ghcr.io/sebadob/rauthy:0.19.2-lite

v0.19.1

This is a small bugfix and compatibility release regarding password reset E-Mails.

The main reason for this release are problems with the Password Reset via E-Mail when users
are using Microsoft (the only service provider where this problems can be replicated 100% of the time)
and / or Outlook. These users were unable to use password reset links at all.
The reason is a "Feature" from Microsoft. They fully scan the user's E-Mails and even follow all links
inside it. The problem is, that the binding cookie from Rauthy will go to the Microsoft servers instead
of the user, making it unusable and basically invalidating everything before the user has any chance to
use the link properly.

The usage of this config variable is highly discouraged, and you should avoid it, if you can.
However, big enterprises are moving slowly (and often not at all). This new config variable can be used
as a last resort, to make it usable by giving up some security.

# This value may be set to 'true' to disable the binding cookie checking
# when a user uses the password reset link from an E-Mail.
#
# When using such a link, you will get a so called binding cookie. This
# happens on the very first usage of such a reset link. From that moment on,
# you will only be able to access the password reset form with this very 
# device and browser. This is just another security mechanism and prevents
# someone else who might be passively sniffing network traffic to extract 
# the (unencrypted) URI from the header and just use it, before the user 
# has a change to fill out the form. This is a mechanism to prevent against
# account takeovers during a password reset.
#
# The problem however are companies (e.g. Microsoft) who scan their customers
# E-Mails and even follow links and so on. They call it a "feature". The
# problem is, that their servers get this binding cookie and the user will be
# unable to use this link himself. The usage of this config option is highly
# discouraged, but since everything moves very slow in big enterprises and
# you cannot change your E-Mail provider quickly, you can use it do just make
# it work for the moment and deal with it later.
#
# default: false
#UNSAFE_NO_RESET_BINDING=false

Changes

• implement UNSAFE_NO_RESET_BINDING like mentioned above
  1f4a146
• prettify the expiry timestamp in some E-Mails
  1173fa0

Bugfixes

• It was possible to get an "Unauthorized Session" error during a password reset, if it has been
  initiated by an admin and / or from another browser.
  e5d1d9d
• Correctly set ML_LT_PWD_FIRST - set the default value in minutes (like documented) instead
  of seconds. New default is ML_LT_PWD_FIRST=4320
  e9d1b56

Images

Postgres

ghcr.io/sebadob/rauthy:0.19.1

SQLite

ghcr.io/sebadob/rauthy:0.19.1-lite

v0.19.0

Solid OIDC Support

This is the main new feature for this release.

With the now accepted RSA signatures for DPoP tokens, the ephemeral, dynamic clients and
the basic serving of webid documents for each user, Rauthy should now fully support Solid OIDC.
This feature just needs some more real world testing with already existing applications though.

These 3 new features are all opt-in, because a default deployment of Rauthy will most probably
not use them at all. There is a whole new section in the Config
called EPHEMERAL CLIENTS where you can configure these things. The 3 main variables you need
to set are:

# 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

Afterward, the only "manual" thing you need to do is to add a custom scope called webid
once via the Admin UI.

EVENT_MATRIX_ERROR_NO_PANIC

This new config variable solves a possible chicken and egg problem, if you use a self-hosted
Matrix server and Rauthy as its OIDC provider at the same time. If both services are offline,
for instance because of a server reboot, you would not be able to start them.

• The Matrix Server would panic because it cannot connect to and verify Rauthy
• Rauthy would panic because it cannot connect to Matrix

Setting this variable to true solves this issue and Rauthy would only log an error in that
case instead of panicking. The panic is the preferred behavior though, because this makes
100% sure that Rauthy will actually be able to send out notification to configured endpoints.

Features

• ~20% smaller binary size by stripping unnecessary symbols
  680d5e5
• Accept DPoP tokens with RSA validations
  daade41
• Dynamically build up and serve custom scopes in the /.well-known/openid-configuration
  904cf09
• A much nicer way of generating both DEV and PROD TLS certificates by using Nioca
  has been integrated into the project itself, as well as the
  Rauthy Book
  463bf8a
  a14beda
• Implement opt-in ephemeral clients
  52c84c2
  617908b
• Implement opt-in basic webid document serving
  bca77f5
  1e32f6f
  79cb836
  55433f4
  3cdf81c
• For developers, a new CONTRIBUTING.md
  guide has been added to get people started quickly
  7c38142
  411393f
• Add a new config variable EVENT_MATRIX_ERROR_NO_PANIC to only throw an error instead of
  panic on Matrix connection errors
  4fc3382
• Not really a bug nor a feature, but the "App Version Update" watcher now remembers a
  sent notification for an update and will only notify after a restart again.
  be19735

Bugfixes

• In a HA deployment, the new integrated health watcher from v0.17.0 could return false positives
  93d75d5
  9bbaeb2
• In v0.18.0 a bug has been introduced because of internal JWKS optimizations. This produced
  cache errors when trying to deserialize cached JWKS after multiple requests.
  3808423

New Contributors

damooo

Images

Postgres

ghcr.io/sebadob/rauthy:0.19.0

SQLite

ghcr.io/sebadob/rauthy:0.19.0-lite

v0.18.0

This is a rather small release.
The main reason it is coming so early is the license change.

License Change To Apache 2.0

With this release, the license of Rauthy is changed from the AGPLv3 to an Apache 2.0.
The Apache is way more permissive and makes the integration with other open source projects and software a lot easier.

DPoP Token Support (Experimental)

The first steps towards DPoP Token support have been made.
It is marked as experimental though, because the other authentication methods have been tested and verified with
various real world applications already. This is not the case for DPoP yet.
Additionally, the only supported alg for DPoP proofs is EdDSA for now. The main reason being that I am using Jetbrains
IDE's and the Rust plugin for both IDEA and RustRover are currently broken in conjunction with the rsa crate
(and some others) which makes writing code with them a nightmare. RSA support is prepared as much as possible
though and I hope they will fix this bug soon, so it can be included.

If you have or use a DPoP application, I would really appreciate testing with Rauthy and to get some feedback, so I
can make the whole DPoP flow more resilient as well.

Please note that Authorization Code binding to a DPoP key is also not yet supported, only the /token endpoint accepts
and validates the DPoP header for now.

Changes

• Experimental DPoP support
  803e312
  51dc320
  4329303
  29dce66

Bugfixes

• Typos have been changed in docs and config
  51dc320
• Listen Scheme was not properly set when only HTTP was selected exclusively
  c002fbe
• Resource links in default error HTML template did not work properly in all locations
  5965d9a

New Contributors

twistedfall

Images

Postgres

ghcr.io/sebadob/rauthy:0.18.0

SQLite

ghcr.io/sebadob/rauthy:0.18.0-lite

v0.17.0

This is a pretty huge update with a lot of new features.

New Features

Support for linux/arm64

With the release of v0.17.0, Rauthy's container images are now multi-platform.

Both a linux/amd64 and a linux/arm64 are supported. This means you can "just use it" now on Raspberry Pi and
others, or on Ampere architecture from Cloud providers without the need to compile it yourself.

Events and Auditing

Rauthy now produces events in all different kinds of situations. These can be used for auditing, monitoring, and so on.
You can configure quite a lot for them in the new EVENTS / AUDIT section in the
Rauthy Config.

These events are persisted in the database, and they can be fetched in real time via a new Server Sent Events(SSE)
endpoint /auth/v1/events/stream. There is a new UI component in the Admin UI that uses the same events stream.
In case of a HA deployment, Rauthy will use one additional DB connection (all the time) from the connection pool
to distribute these events via pg listen / notify to the other members. This makes a much simpler deployment and
there is no real need to deploy additional resources like Nats or something like that. This keeps the setup easier
and therefore more fault-tolerant.

You should at least set EVENT_EMAIL now, if you update from an older version.

Slack and Matrix Integrations

The new Events can be sent to a Slack Webhook or Matrix Server.

The Slack integration uses the simple (legacy) Slack Webhooks and can be configured with EVENT_SLACK_WEBHOOK:

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

The Matrix integration can connect to a Matrix server and room. This setup requires you to provide a few more
variables:

# 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 Slack.
# 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=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

You can configure the minimum event level which would trigger it to be sent:

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

Increasing Login Timeouts

Up until version 0.16, a failed login would extend the time the client needed to wait for the result
artificially until it ended up in the region of the median time to log in successfully.
This was already a good thing to do to prevent username enumeration.
However, this has been improved a lot now.

When a client does too many invalid logins, the time he needs to wait until he may do another try
increases with each failed attempt. The important thing here is, that this is not bound to a user,
but instead to the clients IP.
This makes sure, that an attacker cannot just lock a users account by doing invalid logins and therefore
kind of DoS the user. Additionally, Rauthy can detect Brute-Force or DoS attempts independently of
a users account.

There are certain thresholds at 7, 10, 15, 20, 25 invalid logins, when a clients IP will get fully
blacklisted (explained below) for a certain amount of time. This is a good DoS and even DDoS prevention.

Ip Blacklist Middleware

This is a new HTTP middleware which checks the clients IP against an internal blacklist.

This middleware is the very first thing that is being executed and just returns an HTML page
to a blacklisted client with the information about the blacklisting and the expiry.
This blacklist is in-memory only to be as fast as possible to actually be able to handle brute
force and DoS attacks in the best way possible while consuming the least amount of resources
to do this.

Currently, IP's may get blacklisted in two ways:

• Automatically when exceeding the above-mentioned thresholds for invalid logins in a row
• Manually via the Admin UI

Blacklisted IP's always have an expiry and will get removed from the blacklist automatically.
Both actions will trigger one of the new Rauthy Events and send out notifications.

JWKS Auto-Rotate Scheduler

This is a simple new cron job which rotates the JSON Web Key Set (JWKS) automatically for
enhanced security, just in case one of the keys may get leaked at some point.

By default, it runs every first day of the month. This can be adjusted in the config:

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

Fully Reworked Authentication Middleware

The authentication and authorization system has been fully reworked and improved.

The new middleware and way of checking the client's access rights in each endpoint is way
less error-prone than before. The whole process has been much simplified which indirectly
improves the security:

• CSRF Tokens are now checked automatically if the request method is any other than a GET
• Bearer Tokens are not allowed anymore to access the Admin API
• A new ApiKey token type has been added (explained below)
• Only a single authn/authz struct is needed to validate each endpoint
• The old permission extractor middleware was removed which also increases the performance a bit

New API-Key Type

This new API-Key type may be used, if you need to access Rauthy API from other applications.

Beforehand, you needed to create a "user" for an application, if you wanted to access the API,
which is kind of counter-intuitive and cumbersome.
These new API-Keys can be used to handle this task now. These are static keys with an
optional expiry date and fine-grained access rights. You should only give them permissions
to the resources you actually need to further improve your backend security.

They can be easily created, configured and revoked / deleted in the Admin UI at any time.

IMPORTANt: The API now cannot be accessed anymore with Bearer tokens! If you used this
method until now, you need to switch to the new API Keys

OIDC Client FORCE_MFA feature

In the configuration for each individual OIDC client, you can find a new FORCE MFA switch.
It this new option is activated for a client, it will only issue authentication codes for
those users, that have at least one Passkey registered.
This makes it possible to force MFA for all your different applications from Rauthy directly
without the need to check for the amr claim in the ID token and do or configure all of
this manually downstream. Most of the time, you may not even have control over the client
itself, and you are basically screwed, if the client does not have its own "force mfa integration".

CAUTION: This mentioned in the UI as well, but when you check this new force mfa option,
it can only force MFA for the authorization_code flow of course! If you use other flows,
there just is no MFA that could be checked / forced.

Rauthy Version Checker

Since we do have an Events system now, there is a new scheduled cron job, which checks the
latest available Rauthy Version.

This Job runs once every 8 hours and does a single poll to the Github Releases API. It looks
for the latest available Rauthy Version that is not a prerelease or anything unstable.
If it finds a version higher than the currently running one, a new Event will be generated.
Additionally,
you will see the current Rauthy Version in the UI now and a small indicator just next to it,
if there is a stable update available.

Changes

• Support for linux/arm64
  2abb071
• New events and auditing
  758dda6
  488f9de
  7b95acc
  34d8888
  f70f0b2
  5f0c9c9
  a9af494
  797dad5
  [b338f26](https://github.com/sebadob...

v0.16.1

This is a small bugfix release.

If you had an active and valid session from a v0.15.0, did an update to v0.16.0 and your session was still valid,
it did not have existing information about the peer IP. This is mandatory for a new feature introduced with v0.16.0
though and the warning logging in that case had an unwrap for the remote IP (which can never be null from v0.16.0 on),
which then would panic.

This is a tiny bugfix release that just gets rid of the possible panic and prints UNKNOWN into the logs instead.

Changes

• print UNKNOWN into the logs for non-readable / -existing peer IPs
  6dfd0f4

Images

Postgres

ghcr.io/sebadob/rauthy@sha256:e6b4c990c6317b9f65d7b81a4dee7cccf0e82c602a11f012c4c6086ed0ccd0be

sdobedev/rauthy@sha256:e6b4c990c6317b9f65d7b81a4dee7cccf0e82c602a11f012c4c6086ed0ccd0be

SQLite

ghcr.io/sebadob/rauthy@sha256:91d126209dfb15b092b91a72a65cb3e56c6d048f7b77b21c6e8ed3a0e68a5de1

sdobedev/rauthy@sha256:91d126209dfb15b092b91a72a65cb3e56c6d048f7b77b21c6e8ed3a0e68a5de1

v0.16.0

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:8801d043d2d4483d747d05c6f9a1489db84bd684c8769af3068195888...

v0.15.0

Breaking

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

Changes

This release is all about new Passkey Features.

• A user is not limited to just 2 keys anymore
• During registration, you can (and must) provide a name for the passkey, which helps you identify and distinguish
  your keys, when you register multiple ones.
• The exclude_credentials feature is now properly used and working. This makes sure, that you cannot register the
  same Passkey multiple times.
• The Passkeys / MFA section in the Admin UI has been split from the User Password section to be more convenient to use

Commits:

• New Passkey Features
  d317d90
  cd5d086
  61464bf
  e70c5a7
  bc75610
  49e9630
• New config option WEBAUTHN_FORCE_UV to optionally reject Passkeys without user verification
  c35ecc0
• Better /token endpoint debugging capabilities
  87f7969

Images

Postgres

ghcr.io/sebadob/rauthy@sha256:fb1b26c70f5462a01bd24ce89e7fe77789514866d6c6025d4e640bf4648551e7

sdobedev/rauthy@sha256:fb1b26c70f5462a01bd24ce89e7fe77789514866d6c6025d4e640bf4648551e7

SQLite

ghcr.io/sebadob/rauthy@sha256:78fad52f3d77109e4c5c75b5ccdd024c7b1028d47c4972fb99569fe393fc2497

sdobedev/rauthy@sha256:78fad52f3d77109e4c5c75b5ccdd024c7b1028d47c4972fb99569fe393fc2497

v0.14.5

This is the last v0.14 release.
The next v0.15 will be an "in-between-release" which will do some migration preparations for Webauthn
/ FIDO 2 updates and features coming in the near future.

• Removed duplicate sub claims from JWT ID Tokens
  a35db33
• Small UI improvements:
  • Show loading indicator when doing a password change
  • The Loading animation was changes from JS to a CSS animation
    abd0a06
• Upgrades to actix-web 4.4 + rustls 0.21 (and all other minor upgrades)
  070a453

Images

Postgres

ghcr.io/sebadob/rauthy@sha256:6f139010ec226fa146e85355014951afaab8fcdb29e87b282f6f358838e41fc0

sdobedev/rauthy@sha256:6f139010ec226fa146e85355014951afaab8fcdb29e87b282f6f358838e41fc0

SQLite

ghcr.io/sebadob/rauthy@sha256:d716f1cad1c990c6170d75e393eeacd6930166ee6c07d9b2e8324bf09b4a7b5d

sdobedev/rauthy@sha256:d716f1cad1c990c6170d75e393eeacd6930166ee6c07d9b2e8324bf09b4a7b5d