v0.26.2

Bugfix

This patch reverts an unintended change to the user:group inside the container images.
This will fix issues with migrations from existing deployments using SQLite with manually managed
volume access rights.

v0.26.0 changed from scratch to gcr.io/distroless/cc-debian12:nonroot as the base image for the final deployment.
The distroless image however sets a user of 65532 by default, while it always has been 10001:10001 before.
The affected versions are

• 0.26.0
• 0.26.1

Starting from this release (0.26.2), the user inside the container will be the same one as before:

10001:10001

839724001710cb095f39ff7df6be00708a01801a

Images

Postgres

ghcr.io/sebadob/rauthy:0.26.2

SQLite

ghcr.io/sebadob/rauthy:0.26.2-lite

v0.26.1

Changes

Upstream Auth Provider Query Params

Some upstream auth providers need custom query params appended to their authorization endpoint URL.
Rauthy will now accept URLs in the auth provider config with pre-defined query params, as long as they
don't interfere with OIDC default params.

7dee26a

Option Log Fmt as JSON

To make automatic parsing of logs possible (to some extent), you now have the ability to change the logging output from
text to json with the following new config variable:

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

1ef1353

Bugfix

• With relaxing requirements for password resets for new users, a bug has been introduced that would prevent
  a user from registering an only-passkey account when doing the very first "password reset".
  de2cfea

Images

Postgres

ghcr.io/sebadob/rauthy:0.26.1

SQLite

ghcr.io/sebadob/rauthy:0.26.1-lite

v0.26.0

Breaking

Deprecated API Routes Removal

The following API routes have been deprecated in the last version and have now been fully removed:

• /oidc/tokenInfo
• /oidc/rotateJwk

Base Container Image Change

With this version, Rauthy switches to the rootless version of distroless images.
If you managed your file permissions inside the container manually (for instance for a SQLite file), you may
need to adopt your config.

The user ID inside the container is not 10001 anymore but 65532 instead.

Cache Config

The whole CACHE section in the config has been changed:

#####################################
############## CACHE ################
#####################################

# 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.
# Will be ignored if `HQL_NODE_ID_FROM=k8s`
#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
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
"

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

# 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

# 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

0919767

/auth/v1/health Response Change

The response for /auth/v1/health has been changed.

If you did not care about the response body, there is nothing to do for you. The body itself returns different values
now:

struct HealthResponse {
    db_healthy: bool,
    cache_healthy: bool,
}

0919767

Changes

ZH-Hans Translations

Translations for ZH-Hans have been added to Rauthy. These exist in all places other than the Admin UI, just like the
existing ones already.

ec6c2c3
fcba3c7

Support for deep-linking client apps like Tauri

Up until v0.25, it was not possible to set the Allowed Origin for a client in a way that Rauthy would allow access
for instance from inside a Tauri app. The reason is that Tauri (and most probably others) do not set an HTTP / HTTPS
scheme in the Origin header, but something like tauri://.

Rauthy has now support for such situations with adjusted validation for the Origin values and a new config variable
to allow specific, additional Origin schemes:

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

d52f76c

More stable health checks in HA

For HA deployments, the /health checks are more stable now.
The quorum is also checked, which will detect network segmentations. To achieve this and still make it possible to use
the health check in situations like Kubernetes rollouts, a delay has been added, which will simply always return true
after a fresh app start. This initial delay make it possible to use the endpoint inside Kubernetes and will not prevent
from scheduling the other nodes. This solves a chicken-and-egg problem.

You usually do not need to care about it, but this value can of course be configured:

# 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

5d1ddca

Migration to ruma

To send out Matrix notifications, Rauthy was using the matrix-sdk up until now. This crate however comes with a huge
list of dependencies and at the same time pushes too few updates. I had quite a few issues with it in the past because
it was blocking me from updating other dependencies.

To solve this issue, I decided to drop matrix-sdk in favor of ruma, which it is using under the hood anyway. With
ruma, I needed to do a bit more work myself since it's more low level, but at the same time I was able to reduce the
list of total dependencies Rauthy has by ~90 crates.

This made it possible to finally bump other dependencies and to start the internal switch
from redhac to Hiqlite for caching.

IMPORTANT:
If you are using a self-hosted homeserver or anything else than the official matrix.org servers for Matrix event
notifications, you must set a newly introduced config variable:

# URL of your Matrix server.
# default: https://matrix.org
#EVENT_MATRIX_SERVER_URL=https://matrix.org

0b50376

Internal Migration from redhac to hiqlite

The internal cache layer has been migrated from redhac
to Hiqlite.

A few weeks ago, I started rewriting the whole persistence layer from scratch in a separate project. redhac is working
fine, but it has some issues I wanted to get rid of.

• its network layer is way too complicated which makes it very hard to maintain
• there is no "sync from other nodes" functionality, which is not a problem on its own, but leads to the following
• for security reasons, the whole cache is invalidated when a node has a temporary network issue
• it is very sensitive to even short term network issues and leader changes happen too often for my taste

I started the Hiqlite project some time ago to get rid of these things and have
additional features. It is outsourced to make it generally usable in other contexts as well.

This first step will also make it possible to only have a single container image in the future without the need to
decide between Postgres and SQLite via the tag.

0919767

Local Development

The way the container images are built, the builder for the images is built and also the whole justfile have been
changed quite a bit. This will not concern you if you are not working with the code.

The way of wrapping and executing everything inside a container, even during local dev, became tedious to maintain,
especially for different architectures and I wanted to get rid of the burden of maintenance, because it did not provide
that many benefits. Postgres and Mailcrab will of course still run in containers, but the code itself for backend and
frontend will be built and executed locally.

The reason I started doing all of this inside containers beforehand was to not need a few additional tool installed
locally to make everything work, but the high maintenance was not worth it in the end. This change now reduced the
size of the Rauthy builder image from 2x ~4.5GB down to 1x ~1.9GB, which already is a big improvement. Additionally,
you don't even need to download the builder image at all when you are not creating a production build, while beforehand
you always needed the builder image in any case.

To encounter the necessary dev tools installation and first time setup, I instead added a new just recipe called
setup which will do everything necessary, as long as you have the prerequisites available (which you needed before
as well anyway, apart from npm). This has been updated in the
CONTRIBUTING.md.

Bugfix

• The refresh_token grant type on the /token endpoint did not set the original auth_time for the id_token, but
  instead calculated it from now() each time.
  aa6e07d

Images

Postgres

ghcr.io/sebadob/rauthy:0.26.0

SQLite

ghcr.io/sebadob/rauthy:0.26.0-lite

v0.25.0

Changes

Token Introspection

The introspection endpoint has been fixed in case of the encoding like mentioned in bugfixes.
Additionally, authorization has been added to this endpoint. It will now make sure that the request also includes
an AUTHORIZATION header with either a valid Bearer JwtToken or Basic ClientId:ClientSecret to prevent
token scanning.

The way of authorization on this endpoint is not really standardized, so you may run into issues with your client
application. If so, you can disable the authentication on this endpoint with

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

2e84ceb
7087a59

API Routes Normalization

In preparation for a clean v1.0.0, some older API routes have been fixed regarding their casing and naming.
The "current" or old routes and names will be available for exactly one release and will be phased out afterward
to have a smooth migration, just in case someone uses these renamed routes.

• /oidc/tokenInfo -> /oidc/introspect
• /oidc/rotateJwk -> /oidc/rotate_jwk

Since I don't like kebab-case, most API routes are written in snake_case, with 2 exceptions that follow RFC namings:

• openid-configuration
• web-identity

All the *info routes like userinfo or sessioninfo are not kebab_case on purpose, just to match other IdPs and
RFCs a bit more.

There is not a single camelCase anymore in the API routes to avoid confusion and issues in situations where you could
for instance mistake an uppercase I as a lowercase l. The current camelCase endpoints only exist for a smoother
migration and will be phased out with the next bigger release.

107f148

Config Read

The current behavior of reading in config variables was not working as intended.

Rauthy reads the rauthy.cfg as a file first and the environment variables afterward. This makes it possible to
configure it in any way you like and even mix and match.
However, the idea was that any existing variables in the environment should overwrite config variables and therefore
have the higher priority. This was exactly the other way around up until v0.24.1 and has been fixed now.

How Rauthy parses config variables now correctly:

1. read rauthy.cfg
2. read env var
3. all existing env vars will overwrite existing vars from rauthy.cfg and therefore have the higher priority

28b2457

Bugfixes

• The token introspection endpoint was only accepting requests with Json data, when it should have instead been
  with Form data.

Images

Postgres

ghcr.io/sebadob/rauthy:0.25.0

SQLite

ghcr.io/sebadob/rauthy:0.25.0-lite

v0.24.1

The last weeks were mostly for updating the documentation and including all the new features that came to Rauthy in the last months. Some small things are still missing, but it's almost there.

Apart from that, this is an important update because it fixes some security issues in external dependencies.

Security

Security issues in external crates have been fixed:

• moderate matrix-sdk-crypto
• moderate openssl
• low vodozemac

Changes

S3_DANGER_ACCEPT_INVALID_CERTS renamed

The config var S3_DANGER_ACCEPT_INVALID_CERTS has been renamed to S3_DANGER_ALLOW_INSECURE. This is not a breaking change right now, because for now Rauthy will accept both versions to not introduce a breaking change, but the deprecated value will be removed after v0.24.

S3 Compatibility

Quite a few internal dependencies have been updated to the latest versions (where it made sense).

One of them was my own cryptr. This was using the rusty-s3 crate beforehand, which is a nice one when working with S3 storages, but had 2 issues. One of them is that it is using pre-signed URLs. That is not a flaw in the first place, just a design decision to become network agnostic. The other one was that it signed the URL in a way that would make the request not compatible with Garage. I migrated cryptr to my own s3-simple which solves these issues.

This update brings compatibility with the garage s3 storage for Rauthy's S3 backup feature.

f1eab35

Bugfixes

• Fetching the favicon (and possibly other images) was forbidden because of the new CSRF middleware from some weeks
  ago.
  76cd728
• The UI and the backend had a difference in input validation for given_name and family_name which could make some buttons in the UI get stuck. This has been fixed and the validation for these 2 is the same everywhere and at least 1 single character is required now.
  19d512a

Images

Postgres

ghcr.io/sebadob/rauthy:0.24.1

SQLite

ghcr.io/sebadob/rauthy:0.24.1-lite

v0.24.0

Many thousands of lines have been refactored internally to provide better maintainability in the future.
These are not mentioned separately, since they did not introduce anything new. Apart from this, there are only small
changes, but one of them is an important breaking change.

Breaking

TRUSTED_PROXIES Config Variable

The new config variable TRUSTED_PROXIES introduces a breaking change in some cases.
If you are running Rauthy with either PROXY_MODE=true or with a set PEER_IP_HEADER_NAME value, you must add the
TRUSTED_PROXIES to your existing config before updating.

This value specifies trusted proxies in the above situation. The reason is that Rauthy extracts the client IP from
the HTTP headers, which could be spoofed if they are used without validating the source. This was not a security issue,
but gave an attacker the ability to blacklist or rate-limit IPs that do not belong to him.

When PROXY_MODE=true or set PEER_IP_HEADER_NAME, Rauthy will now only accept direct connections from IPs specified
with TRUSTED_PROXIES and block all other requests. You can provide a list of CIDRs to have full flexibility for your
deployment.

# 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
#10.0.0.0/8
#"

Note:
Keep in mind, that you must include IPs for direct health checks like for instance inside Kubernetes here,
if they are not being sent via a trusted proxy.

e1ae491

Features

User Registration Domain Blacklisting

If you are using an open user registration without domain restriction, you now have the possibility to blacklist
certain E-Mail provider domains. Even if your registration endpoint allows registrations, this blacklist will be
checked and deny requests with these domains.
This is mainly useful if you want to prevent malicious E-Mail providers from registering and spamming your database.

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

824b109

Changes

Even though it was not needed so far, the OIDC userinfo endpoint now has a proper POST handler in addition to the
existing GET to comply with the RFC.
05a8793

Bugfixes

• The upstream crate curve25519-dalek had a moderate timing variability security issue
  8bb4069

Images

Postgres

ghcr.io/sebadob/rauthy:0.24.0

SQLite

ghcr.io/sebadob/rauthy:0.24.0-lite

v0.23.5

Upstream IdP Locale Fix

This patch fixes a regression from fixing the special characters encoding in upstream IdP JWT tokens. A panic was
possible when the upstream IdP did not include a locale in the id_token.
ea24e7e
481c9b3

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.5

SQLite

ghcr.io/sebadob/rauthy:0.23.5-lite

v0.23.4

This is a tiny update, but brings an important bugfix for upstream IdPs.

Bugfix

A bug has been fixed in case an upstream IdP included special characters inside Strings in the returned JWT token after
a successful user login flow.
Since JWT tokens should use UNICODE encoding in these cases, it is not possible to do zero-copy deserialization into
Rust UTF8 string slices in that case. This has been fixed in a way, that only when there are existing special
characters, Rauthy will now do the additional, necessary String allocations for the deserialization process.
This should fix current issues when logging in via an upstream IdP with special characters inside the E-Mail address for
instance.
aa97cb8

Apart from that, there were some minor UX improvements for the Admin UI providers setup page like earlier client side
checking of variables and preventing form submission when some required ones were missing.
9a227c9
c89fb7f

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.4

SQLite

ghcr.io/sebadob/rauthy:0.23.4-lite

v0.23.3

Changes

Documentation Updates

Updated sections in the documentation for:

• Choose database in Getting Started
• Started a new page for production setup
• Info on Android passkey status
• Encryption section
• Getting Started with Kubernetes

9f85c77

More strict origin checking

More strict checking and validation for allowed_origins has been implemented, when you configure clients. Before,
the regex only checked for the input to be a valid URI, which is not strict enough for validation an origin.
This should improve the UX and prevents hard to debug bugs, when someone enters an invalid origin.

At the same time, a better visual separation has been added to the Origins / URI section in the UI when configuring
clients.

55704f3
d993d42
8d4e455

Small performance optimizations

Small improvements have been made in a lot of places, which resulted in less memory allocations.
9144f2a

POST /authorize simplification

The logic on POST /authorize has been simplified internally. The code grew to an over-complicated state with new
features coming in all the time until a point where it was hard to follow. This has been simplified.
This makes the software better maintainable in the future.
af0db9d

Bugfix

• add all /fed_cm/ routes as exceptions to the new CSRF protection middleware
  360ce46
• upstream auth provider templates could get stuck in the UI when switching between them
  d2b928a
• when a problem with an upstream provider occurs on /callback, you will now see the detailed error in the UI
  8041c95

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.3

SQLite

ghcr.io/sebadob/rauthy:0.23.3-lite

v0.23.2

Changes

New CSRF protection middleware

CSRF protection was there already without any issues.
However, a new middleware has been added to the whole routing stack in addition to the existing checks. This provides
another defense in depth. The advantage of the new middleware is, that this can be enforced all the way in the future
after enough testing in parallel.
If this works fine without any issues, we might get rid of the current way of doing it and only use the new middleware,
which is easier to maintain and to work with.

To not break any existing deployments and make sure I did not forget route exceptions for the new middleware, you can
set it to warn-only mode for this minor release. This option will be removed in future releases though and should only
be a temporary solution:

# 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

97fedf1

Experimental FedCM support

This is not really considered a new feature, but Rauthy now has experimental support for FedCM in its current state.
This is opt-in and disabled by default. You should not attempt to use it in production because the FedCM implementation
itself still has a few bumps and sharp edges.
The only reason the experimental support is there is to help smooth out these things and hopefully have FedCM as a
really nice addition. It does not really bring any new possibilities to the table, but it would improve the UX quite a
bit, if it hopefully turns out great.

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

4689e54

Relaxed validation on ephemeral client_ids

The input validation for ephemeral client_ids has been relaxed. This now makes it possible to test them with OIDC
playgrounds, which typically generate pretty long testing URLs, which were being rejected for their length beforehand.
Rauthy now accepts URLs of up to 256 characters as client_ids.
62405bb

Bumped Argon2ID defaults

The default values for the Argon2ID hashing algorithm have been bumped up quite a bit. Rauthy's goal is to be as secure
as possible by default. The old values were quite a bit above the OWASP recommendation, but still way too low imho.
The values will of course still need tuning and adjustment to the target architecture / deployment, but they provide a
way better starting point and can be considered really secure even if not adjusted.

The new defaults are:

# 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

5145889
feee23e

Bugfixes

• Ephemeral client's now work properly with the /userinfo endpoint in strict-validation mode. Their validation is
  simply being skipped at that point, because it does not make much sense to do an enabled check at that point.
  90b0367
• A small bug appeared in the UI after you have added new custom user attributes. Instead of resetting the input
  values to empty strings after the registration, they were set to undefined.
  ab77595
• Because of a bug in the account overview UI, it was not possible to link an already existing account to an upstream
  IdP after the registration.
  22751ee

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.2

SQLite

ghcr.io/sebadob/rauthy:0.23.2-lite