Releases: sebadob/rauthy
v0.29.4
Changes
Custom Attributes via SCIM
Rauthy's SCIM functionality now also adds custom user attributes. These will be added, just like inside the id_token claims, under custom: * as JSON values. These will be added only if the client should receive these attributes defined via the allowed scopes.
This is a non-RFC value, but it should be ignored by any client, that does not understand the custom field. While the rauthy-client has been released with a new version in the meantime, its implementation gives you access to custom attributes, if some exist.
Bugfix
- It was possible, that Rauthy tried to sync groups via SCIM even if group syncing has been disabled.
#936 - The legacy Rauthy logo showed up at the login page in versions
0.29.0-0.29.3for fresh Hiqlite deployments. This was due to a missing, permanent database migration that removes the old logo. This was shadowed by the manual version migration queries that existed during the0.28release. This patch version has a programmatic query and will add a permanent migration with the0.30release to not introduce breaking changes with a patch level.
#943
v0.29.3
Bugfix
v0.29.2s fix for the HTTP 302 instead of 200 on/logoutbroke the logout from the UI without additionalid_token_hint.
#930- Form validation for Upstream Auth Provider config did not set some fields to required under certain conditions and would therefore return the backend validation error instead of a nicer way of handling it.
#931 - Fixed another DB migration query between Hiqlite and Postgres.
#932
v0.29.2
v0.29.1
Bugfix
- Because of the default admin renaming with
0.29.0, the 2 test admin accounts have not been deleted when starting up a new production instance.
#909 - Error logs with an invalid
rauthy.cfghave been emitted as tracing logs instead ofeprintln, when logging was not initialized yet.
#910 - Because of the new session validation rework and additional safety-nets, a login was impossible when
SESSION_VALIDATE_IP=false
#911
v0.29.0
Breaking
Postgres: sqlx dropped in favor of tokio-postgres
Internally, quite a big change has happened. sqlx has been completely dropped in favor of tokio-postgres in combination with some other dependencies. This solved a few issues.
sqlx has been blocking updates quite a few times in the past. It pulls in a huge amount of dependencies, even if they are not used, which often block other crates. It's also pretty slow with updates, which means you might be forced to stick with older versions for several months, and it has some other limitations I don't like.
Even though the compile-time checked queries are the best feature of sqlx, they also produced a lot of issues and confusion when other people were trying to build from source, and so on.
The bonus for everyone not working with the code directly is, that tokio-postgres has about half the latency of sqlx in my testing.
The breaking change that comes with this internal change is actually a good one:
You don't specify the DATABASE_URL like before. DATABASE_URL and DATABASE_MAX_CONN have been completely removed. Instead, you now have separate config vars for each part of the URL. This removes the limitation that you could only have alphanumeric characters inside your password (otherwise the URL would be invalid).
One additional thing is, that sqlx silently ignored TLS certificate validation if it failed, which is actually a pretty bad behavior. If you are running a Postgres with self-signed certificates, you need to explicitly allow this.
You now need to provide the following values, if you are using Postgres:
# If you set `HIQLITE=false` and want to use Postgres as your database,
# you need to set the following variables:
PG_HOST=
# default: 5432
#PG_PORT=5432
PG_USER=
PG_PASSWORD=
# default: rauthy
#PG_DB_NAME=rauthy
# If your database uses a self-signed certificate, which cannot
# be verified, you might want to set this to `true`.
# default: false
#PG_TLS_NO_VERIFY=false
# Max DB connections for the Postgres pool.
# default: 20
#PG_MAX_CONN=20
CAUTION: This is a pretty big change, because existing sqlx migrations will be converted manually. Just to be safe, you should probably do a database backup before starting v0.29!
Default Admin change
The default admin has been changed from admin@localhost.de to just admin@localhost. This is due to the fact that localhost.de is a real domain with a valid TLD and it could introduce issues, if these users exist on a Rauthy instance.
If you still had an admin@localhost.de around in your database, this will also be changed even for an existing deployment! You will see a warn! logging during the whole v0.29 release to make you aware of this. After the new version has been started up, your default admin will be admin@localhost.
Additional PoW requirements
If you have been providing your own, custom login UI, be aware of the fact that the LoginRequest + ProviderLoginRequest now require a solved PoW inside the request body. For further information about this, see the notes down below -> Defense in depth;
Internal Metrics now opt-in
The internal /metrics HTTP server is not used by most people, but it has been enabled by default, while using ~10mb of memory in idle and adding the overhead to each API request that metrics are actually collected internally. For this reason, the internal metrics (and therefore also internal Swagger UI) are not opt-in instead of opt-out. If you are using prometheus metrics right now, make sure that you explicitly set
METRICS_ENABLE=true
Removed Custom CA from Auth Providers
The custom root CA option has been removed from Upstream Auth Providers. This was due to performance and efficiency optimizations. There is a new global HTTP client (mentioned below) which will handle custom root CAs and will be used for auth providers as well.
If you are currently using an upstream auth provider with a custom root CA, make sure to add this CA to HTTP_CUST_ROOT_CA_BUNDLE as mentioned further down below`
Changes
OpenID Connect Backchannel Logout
Rauthy now supports OpenID Connect Backchannel Logout.
If downstream clients support it, you can now provide a backchannel_logout_uri in the config view via the Admin UI. Rauthy itself can act as a downstream client for an upstream as well. The default /auth/v1/oidc/logout endpoint now optionally accepts the logout_token and will propagate Backchannel Logouts, if the token is actually coming from a valid, configured upstream auth provider.
Backchannel Logouts will of course also be triggered in other situations like forced session invalidation by an admin, user expiration, or deletion, and so on.
The feature can be seen as in beta state now. Everything has been implemented following the RFC and basic integration tests exist. However, to catch some weird edge cases, it needs testing in the real world as well. If you have any problems using it, please open an issue about it.
There are some new config variables:
#####################################
######## BACKCHANNEL LOGOUT #########
#####################################
# The maximum amount of retries made for a failed backchannel logout.
# Failed backchannel logouts will be retried every 60 - 90 seconds
# from all cluster nodes. The timeout between retries is randomized
# to avoid overloading clients. It will be executed on each cluster
# member to increase the chance of a successful logout in case of
# network segmentations.
# default: 100
#BACKCHANNEL_LOGOUT_RETRY_COUNT=100
# Can be set to `true` to allow plain HTTP backchannel
# logout requests.
# default: false
#BACKCHANNEL_DANGER_ALLOW_HTTP=false
# Can be set to `true` to allow insecure HTTPS logout requests.
# This will disable TLS certificate validation.
# default: false
#BACKCHANNEL_DANGER_ALLOW_INSECURE=false
# The lifetime / validity for Logout Tokens in seconds.
# These Logout Tokens are being generated during OIDC
# Backchannel Logout requests to configured clients.
# The token lifetime should be as short as possible and
# at most 120 seconds.
# default: 30
#LOGOUT_TOKEN_LIFETIME=30
# You can allow a clock skew during the validation of
# Logout Tokens, when Rauthy is being used as a client
# for an upstream auth provider that uses backchannel
# logout.
#
# The allowed skew will be in seconds and a value of
# e.g. 5 would mean, that 5 seconds are added to the
# `iat` and `exp` claim validations and expand the range.
#
# default: 5
#LOGOUT_TOKEN_ALLOW_CLOCK_SKEW=5
# The maximum allowed lifetime for Logout Tokens.
# This value is a security check for upstream auth
# providers. If Rauthy receives a Logout Token, it will
# check and validate, that the difference between `iat`
# and `exp` is not greater than LOGOUT_TOKEN_ALLOWED_LIFETIME.
# This means Rauthy will reject Logout Tokens from clients
# with a way too long validity and therefore poor
# implementations. The RFC states that tokens should
# be valid for at most 120 seconds.
# default: 120
#LOGOUT_TOKEN_ALLOWED_LIFETIME=120
RP Initiated Logout
While implementing OpenID Connect Backchannel Logout, support for RP Initiated Logout has been added as well to provide a complete package.
SCIM
This version brings SCIM support to Rauthy.
You can define a custom SCIM base uri per client. The client must support SCIM v2 and the filter parameter. Groups syncing is optional.
You can also define a group prefix which will act as a filter for the to-be-synced data. For instance, if you define a prefix of myapp:, only the groups starting with it will be synced, like e.g. myapp:admin, myapp:user. Additionally, only users that are assigned to at least one of these filtered groups will by synced, while others are skipped.
The advantage of this is, let's say you have an application with limited seats, or where each existing user costs a license (Gitlab Enterprise would be an example), you need to pay for each registered user. If you now split your users into groups and only your developers need to exist on that instance, you can assign a group like dev:* and only sync the dev: groups via SCIM.
The SCIM impl is not integration tested, as this usually requires an external deployment. For the future, the idea is to implement the client side into the rauthy-client and use this for integration testing against itself. However, I followed the RFC closely and tested all operations manually against https://scim.dev .
Just as for the OIDC Backchannel Logout, this feature can be seen as in beta state now. We need some real world testing next, but I think it should be just fine.
#####################################
############### SCIM ################
#####################################
# If set to `true`, already possibly synced groups / users on a
# SCIM server may be deleted if either sync if disabled further
# down the road.
# Depending on your clients specifically, deleting a group / user
# can have a major impact, like e.g. maybe the user had important
# data inside that application that would be deleted automatically
# as well. Depending on your use case, you may want to handle
# deletions manually.
#
# If set to false, only the `exter...
v0.28.3
v0.28.2
Important
This is a pretty important bugfix update. The 0.28 versions before had an error where the groups config component in the Admin UI has been changed to contain roles after the first render. This means, if you have saved a user in the Admin UI (even without changing groups), the groups might have been changed depending on your setup.
The backend sanitizes any submitted roles / groups on user updates, so only actually existing values can exist, but if you had a roles / groups combination with the exact same naming, like e.g. an admin role and an admin group, it could have been possible that a user ends up with a group assignment he should not have. At the same time, a user might have had some groups removed he had before.
This situation can only occur on users you have updated via the Admin UI with either 0.28.0 or 0.28.1. You should update to 0.28.2 asap and double check group assignments for your users you may have updated with an earlier 0.28 version via the Admin UI.
Bugfix
- Fixes a bug in the Admin UI / Users view where the content of the
groupsconfig component containedrolesinstead of groups.
#790
v0.28.1
Security
CVE-2025-29787
Rauthy itself has not been vulnerable, but he zip dependency pulled in by the Swagger UI as a 3rd party dependency has
been vulnerable when reading files. zip inside the Swagger UI has only been used at build time, never at runtime.
However, the version has been bumped to a non-vulnerable one.
Changes
Updated Translations
zh and ko translations have received updates. ko is now also available for the Admin UI and has been added to the
FILTER_LANG_ADMIN value from the 0.28.0 release.
Bugfix
v0.28.0
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 i...
v0.27.3
Changes
Upstream Identity Providers
To provide additional compatibility for some upstream providers like Active Directory Federation Severices, some changes have been applied to Rauthy's behavior.
The first thing is that the HTTP client used for upstream Logins does not force TLS v1.3 anymore, but also allows TLS v1.2. Both v1.2 and v1.3 are considered being secure by current standards. This is necessary, because some OSes like Windows Server 2019 do not support TLS 1.3.
The second change is for the way upstream providers are configured. The behavior until now was, that Rauthy added the client redentials as both Basic Authentication in headers, and in the body for maximum compatibility. However, some IdP'S (like ADFS for nstance) complain about this and only expect it in one place. To make this happen, there are 2 new fields for the upstream IdP onfiguration:
client_secret_basic: boolclient_secret_post: bool
These are available as switches in the Admin UI for each upstream provider. To not introduce breaking changes, all possibly existing configurations will have both options enabled like it has been up until now.
Note
Even though this changes the request and response objects on the API, this change is NOT being handled as a breaking change. API clients are forbidden to modify upstream IdPs for security reasons, which means this change should only affect the Rauthy Admin UI.
Gitlab as Upstream IdP
Gitlab is special and does its own, annoying thing to make it usable as an upstream IdP. An issue has been found when someone tries to log in with no publicly shown email address. In this worst case scenario, a successful login via Github while retrieving all necessary information (email is mandatory for Rauthy), you need to do 3 different API requests.
This version also makes it possible to log in via Github IdP with an account with only private email addresses. A different scope for the login is necessary to make this possible. The template in the UI has been updated, but this will not affect existing Github IdP Providers. If you are currently using Github as upstream IdP, please change the scope manually from read:user to user:email.
Bugfix
- During the deletion of a custom scope, that has been mapped to only a clients default scopes, but not the free ones, the mapping would be skipped during the whole client cleanup and end up being left-over after the deletion, which needed a manual cleanup afterward.
#663