Breaking
Environment Variable Only Config
If you configured Rauthy via environment variables only, you might have breaking changes with this update.
If a configuration is being made purely via env vars, and a proper rauthy.cfg (at least an empty file) is not being
created and mounted inside the container, the application would actually use demo values as long as they are not
overwritten by env vars manually.
To improve the security out of the box, the container setup has been changed and the demo config has a separate
filename, which will only be parsed when LOCAL_TEST=true is passed in as an env var before app startup.
Setting this value inside the usual rauthy.cfg has no effect.
The insecure local testing values that have been set before (again, with an env vars only setup), can be found here
https://github.com/sebadob/rauthy/blob/v0.27.3/rauthy.deploy.cfg for reference, so you can check, if you would have
breaking changes.
If no rauthy.cfg is ever being created, default values will be used, and you can configure the application safely
with env vars only. If you decide to use both, env vars will keep on having the higher priority over values set inside
the config file, just like it has been before.
Changed header names for session CSRF and password reset tokens
This may concern you, if you have built custom UI parts in front of Rauthy.
The Headers names for the session and password reset CSRF tokens have been changed and now contain a leading x-.
This make the API more clean, since custom headers should be marked with a leading x-.
csrf-token->x-csrf-tokenpwd-csrf-token->x-pwd-csrf-token
Custom Client Branding
With the migration to Svelte 5 (mentioned below), the way theming is done has been changed from the ground up in such
a way, that it is not possible to migrate possibly existing custom client branding. This means that you will lose and
need to re-create a possibly existing custom branding with this version.
Paginated Users / Sessions
This may only concern you if you are doing direct API calls to GET users or sessions on a very big Rauthy instance
in combination with server side pagination. When you added backwards=true before, the offset of a single page has
been added automatically in the backend. This is not the case anymore to provide more flexibility with this API. You
need to add the offset yourself now while going backwards.
Security
CVE-2025-24898
Even though the vulnerable code blocks have not been used directly, the openssl and openssl-sys dependencies have
been bumped to fix CVE-2025-24898.
GHSA-67mh-4wv8-2f99
This could have only been affecting dev environments, not any production build,
but GHSA-67mh-4wv8-2f99 has been fixed by bumping frontend
dependencies.
Changes
Svelte 5 Migration
The whole UI has been migrated to Svelte 5 + Typescript. Many parts and components have been re-written from the ground
up to provide a better DX and maintainability in the future.
This whole migration comes with a lot of changes, most of them under the hood regarding performance and efficiency.
There are so many changes, that it does not make much sense to list them all here, but the TL;DR is:
- The whole UI is now based on Svelte 5 + TS with improved performance.
- The DX and UX has been improved a lot.
- Accessibility has been improved by a huge margin.
- Rauthy now comes with a light and dark mode, even for the custom client branding login site.
- We have a new logo, which makes it a lot easier to identify Rauthy in a tab overview and so on.
- The whole UI is now fully responsive and usable even down to mobile devices.
- The whole design of the UI has been changed in a way that most components and payloads can now be cache infinitely.
- The engine for server side rendering of the static HTML content has been migrated
from askama to rinja (based on askama with
lots of improvements). - The backend now comes with caching and dynamic pre-compression of all dynamic SSR HTML content.
- The way i18n is done has been changed a lot and moved from the backend into a type-checked frontend file to make
it a bit easier to get into and provide caching again. - The admin UI can now be translated as well. The i18n for common user sites and the admin UI are split for reduced
payloads for most users. Currently, onlyenanddeexist for the Admin UI, but these can be extended easily in
the future as soon as someone provides a PR. They are also independent with the only requirement that a common i18n
must exist before an admin i18n. (Translations for E-Mails are still in the backend of course) - Part of the state for the Admin UI has been moved into the URL, which makes it possible to copy & paste most links
and actually end up where you were before.
NOTICE: Since the whole UI has basically been re-written, or at least almost every single line has been touched, the
new UI can be seen as in beta state. If you have any problems with it, please open an issue.
User Pictures / Avatars
It is now possible to upload an avatar / picture for each user. This can be done via the account dashboard.
Rauthy uses the term picture to match the OIDC RFC spec. If the scope during login includes profile and the user
has a picture, the picture claim will be included in the id_token and will contain the URL where the user picture
can be found.
User Picture URLs are "safe" to be used publicly, and they contain 2 cryptographically random secure IDs. This makes it
possible to even make them available without authentication for ease of use. By default, a session / API Key / token
is required to fetch them, but you can opt-out of that.
For storage options, the default is database. This is not ideal and should only be done for small instances with maybe
a few hundred users. They can fill up the database pretty quickly, even though images are optimized after upload, they
will end up somewhere in the range of ~25 - 40kB each.
For single instance deployments, you can use local file storage, while for HA deployments, you should probably use
an S3 bucket to do so.
Uploading user pictures can be disabled completely by setting PICTURE_STORAGE_TYPE=disabled
The following new config variables are available:
#####################################
########## User Pictures ############
#####################################
# The storage type for user pictures.
# By default, they are saved inside the Database, which is not ideal.
# If you only have a couple hundred users, this will be fine, but
# anything larger should use an S3 bucket if available. For single
# instance deployments, file storage to local disk is available
# as well, but this must not be used with multi replica / HA
# deployments.
# Images will ba reduced in size to max 192px on the longest side.
# They most often end up between 25 - 40kB in size.
#
# Available options: db file s3 disabled
# Default: db
#PICTURE_STORAGE_TYPE=db
# If `PICTURE_STORAGE_TYPE=file`, the path where pictures will be
# saved can be changed with this value.
# default: ./pictures
#PICTURE_PATH="./pictures"
# Access values for the S3 bucket if `PICTURE_STORAGE_TYPE=s3`.
# Not needed otherwise.
#PIC_S3_URL=https://s3.example.com
#PIC_S3_BUCKET=my_bucket
#PIC_S3_REGION=example
#PIC_S3_KEY=s3_key
#PIC_S3_SECRET=s3_secret
# default: true
#PIC_S3_PATH_STYLE=true
# Set the upload limit for user picture uploads in MB.
# default: 10
#PICTURE_UPLOAD_LIMIT_MB=10
# By default, user pictures can only be fetched with a valid
# session, an API Key with access to Users + Read, or with a
# valid token for this user. However, depending on where and
# how you are using Rauthy for your user management, you may
# want to make user pictures available publicly without any
# authentication.
#
# User Picture URLs are "safe" in a way that you cannot guess
# a valid URL. You will need to know the User ID + the Picture
# ID. Both values are generated cryptographically secure in the
# backend during creation. The Picture ID will also change
# with every new upload.
#
# default: false
#PICTURE_PUBLIC=false
Static HTML + prepared queries added to version control
To make it possible to build Rauthy from source in environments like e.g. FreeBSD, all pre-built static HTML files have
been added to version control, even though they are built dynamically each time in release pipelines. Additionally, all
DB queries used by sqlx are added to version control as well.
The reason is that the UI cannot be built in certain environments. With these files checked-in, you can build from
source with just cargo build --release by having Rust available. You don't need to build the UI or have a Postgres
running anymore, if you only care about building from source.
I18n - Korean
Korean has been added to the translations for all user-facing UI parts.
#670
Filter I18n UI Languages
Since it is likely that the available translations will expand in the future and you may not need or
want to show all options to the users, because you maybe only have a local / regional deployment, you
can now apply a filter to the Languages that are shown in the UI selector.
#####################################
############### I18n ################
#####################################
# Can be set to filter the languages to show in the UI.
# If not set, all available i18n translations will be
# show in the language selector.
# To show only specific ones, provide them here as a
# space-separated value.
#
# Languages for all user-facing pages.
# Available Options: en de zhhans ko
#FILTER_LANG_COMMON="en de zhhans ko"
# Languages for the Admin UI.
# Available Options: en de
#FILTER_LANG_ADMIN="en de"
Manual Debug impls
For types in the background, that hold sensitive data like passwords or client secrets, manual impls for Debug have
been added to make sure that no sensitive information can leak into logs with LOG_LEVEL=debug.
CAUTION: If you enable HQL_LOG_STATEMENTS=true for DB statement logging, it is guaranteed that you will see sensitive
information in logs sooner or later, so be very careful when using this in production.
Bugfix
- When using the
MIGRATE_DB_FROMin combination with a Sqlite DB as base that has been created with
Rauthy <v0.20.0, the migration might fail for you inv0.27.0because of an old value in theconfig
table that might not have been cleaned up properly in some cases.
#669 - Fixed a regression from v0.27.0 which made it impossible to use
zh-Hansas a users' language. The deserialization
of the database value would fail when using Hiqlite.
#693 - Fixed a bug in the UI - Custom User Attributes: When only a single existing attribute has been deleted, the
list would not properly update and remove it.
#695 - Type information has been missing for a few endpoints in the OpenAPI definition, which have been fixed in various
PRs.