v0.21.1

Changes

• host .well-known additionally on root /
  3c594f4

Bugfix

• Correctly show the registration_endpoint for dynamic client registration in the openid-configuration
  if it is enabled.
  424fdd1

Images

Postgres

ghcr.io/sebadob/rauthy:0.21.1

SQLite

ghcr.io/sebadob/rauthy:0.21.1-lite

v0.21.0

Breaking

The access token's sub claim had the email as value beforehand. This was actually a bug.
The sub of access token and id token must be the exact same value. sub now correctly contains the user ID,
which is 100% stable, even if the user changes his email address.
This means, if you used the sub from the id token before to get the users email, you need to pay attention now.
The uid from the id token has been dropped, because this value is now in sub. Additionally, since many
applications need the email anyway, it makes sense to have it inside the access token. For this purpose, if email
is in the requested scope, it will be mapped to the email claim in the access token.

Features

OpenID Core Compatibility

Rauthy should now be compliant with the mandatory part of the OIDC spec.
A lot of additional things were already implemented many versions ago.
The missing thing was respecting some additional params during GET /authorize.

OpenID Connect Dynamic Client Registration

Rauthy now supports Dynamic Client registration as defined here.

Dynamic clients will always get a random ID, starting with dyn$, followed by a random alphanumeric string,
so you can distinguish easily between them in the Admin UI.
Whenever a dynamic client does a PUT on its own modification endpoint with the registration_token it
received from the registration, the client_secret and the registration_token will be rotated and the
response will contain new ones, even if no other value has been modified. This is the only "safe" way to
rotate secrets for dynamic clients in a fully automated manner. The secret expiration is not set on purpose,
because this could easily cause troubles, if not implemented properly on the client side.
If you have a
badly implemented client that does not catch the secret rotation and only if you cannot fix this on the
client side, maybe because it's not under your control, you may deactivate the auto rotation with
DYN_CLIENT_SECRET_AUTO_ROTATE=false. Keep in mind, that this reduces the security level of all dynamic
clients.

Bot and spam protection is built-in as well in the best way I could think of. This is disabled, if you set
the registration endpoint to need a DYN_CLIENT_REG_TOKEN. Even though this option exists for completeness,
it does not really make sense to me though. If you need to communicate a token beforehand, you could just
register the client directly. Dynamic clients are a tiny bit less performant than static ones, because we
need one extra database round trip on successful token creation to make the spam protection work.
However, if you do not set a DYN_CLIENT_REG_TOKEN, the registration endpoint would be just open to anyone.
To me, this is the only configuration for dynamic client registration, that makes sense, because only that
is truly dynamic. The problem then are of course bots and spammers, because they can easily fill your
database with junk clients. To counter this, Rauthy includes two mechanisms:

• hard rate limiting - After a dynamic client has been registered, another one can only be registered
  after 60 seconds (default, can be set with DYN_CLIENT_RATE_LIMIT_SEC) from the same public IP.
• auto-cleanup of unused clients - All clients, that have been registered but never used, will be deleted
  automatically 60 minutes after the registration (default, can be set with DYN_CLIENT_CLEANUP_MINUTES).

There is a whole new section in the config:

#####################################
########## DYNAMIC CLIENTS ##########
#####################################

# If set to `true`, dynamic client registration will be enabled.
# Only activate this, if you really need it and you know, what
# you are doing. The dynamic client registration without further
# restriction will allow anyone to register new clients, even
# bots and spammers, and this may create security issues, if not
# handled properly and your users just login blindly to any client
# they get redirected to.
# default: false
#ENABLE_DYN_CLIENT_REG=false

# If specified, this secret token will be expected during
# dynamic client registrations to be given as a
# `Bearer <DYN_CLIENT_REG_TOKEN>` token. Needs to be communicated
# in advance.
# default: <empty>
#DYN_CLIENT_REG_TOKEN=

# The default token lifetime in seconds for a dynamic client,
# that will be set during the registration.
# This value can be modified manually after registration via
# the Admin UI like for any other client.
# default: 1800
#DYN_CLIENT_DEFAULT_TOKEN_LIFETIME=1800

# If set to 'true', client secret and registration token will be
# automatically rotated each time a dynamic client updates itself
# via the PUT endpoint. This is the only way that secret rotation
# could be automated safely.
# However, this is not mandatory by RFC and it may lead to errors,
# if the dynamic clients are not implemented properly to check for
# and update their secrets after they have done a request.
# If you get into secret-problems with dynamic clients, you should
# update the client to check for new secrets, if this is under your
# control. If you cannot do anything about it, you might set this
# value to 'false' to disable secret rotation.
# default: true
#DYN_CLIENT_SECRET_AUTO_ROTATE=true

# This scheduler will be running in the background, if
# `ENABLE_DYN_CLIENT_REG=true`. It will auto-delete dynamic clients,
# that have been registered and not been used in the following
# `DYN_CLIENT_CLEANUP_THRES` hours.
# Since a dynamic client should be used right away, this should never
# be a problem with "real" clients, that are not bots or spammers.
#
# The interval is specified in minutes.
# default: 60
#DYN_CLIENT_CLEANUP_INTERVAL=60

# The threshold for newly registered dynamic clients cleanup, if
# not being used within this timeframe. This is a helper to keep
# the database clean, if you are not using any `DYN_CLIENT_REG_TOKEN`.
# The threshold should be specified in minutes. Any client, that has
# not been used within this time after the registration will be
# automatically deleted.
#
# Note: This scheduler will only run, if you have not set any
# `DYN_CLIENT_REG_TOKEN`.
#
# default: 60
#DYN_CLIENT_CLEANUP_MINUTES=60

# The rate-limiter timeout for dynamic client registration.
# This is the timeout in seconds which will prevent an IP from
# registering another dynamic client, if no `DYN_CLIENT_REG_TOKEN`
# is set. With a `DYN_CLIENT_REG_TOKEN`, the rate-limiter will not
# be applied.
# default: 60
#DYN_CLIENT_RATE_LIMIT_SEC=60

Better UX with respecting login_hint

This is a small UX improvement in some situations. If a downstream client needs a user to log in, and it knows
the users E-Mail address somehow, maybe because of an external initial registration, It may append the correct
value with appending the login_hint to the login redirect. If this is present, the login UI will pre-fill the
E-Mail input field with the given value, which make it one less step for the user to log in.

Changes

• The /userinfo endpoint now correctly respects the scope claim from withing the given Bearer token
  and provides more information. Depending on the scope, it will show the additional user values that were
  introduced with v0.20
  49dd553
• respect max_age during GET /authorize and add auth_time to the ID token
  9ca6970
• correctly work with prompt=none and prompt=login during GET /authorize
  9964fa4
• Make it possible to use an insecure SMTP connection
  ef46414
• Implement OpenID Connect Dynamic Client Registration
  b48552e
  12179c9
• respect login_hint during GET /authorize
  963644c

Bugfixes

• Fix the link to the latest version release notes in the UI, if an update is available
  e66e496
• Fix the access token sub claim (see breaking changes above)
  29dbe26
• Fix a short route fallback flash during Admin UI logout
  6787261

Images

Postgres

ghcr.io/sebadob/rauthy:0.21.0

SQLite

ghcr.io/sebadob/rauthy:0.21.0-lite

v0.20.1

This is a small bugfix release.
The temp migrations which exist for v0.20 only to migrate existing database secrets to cryptr were causing a crash at startup for a fresh installation.
This is the only thing that has been fixed with this version. They are now simply ignored and a warning is logged into the console at the very first startup.

Images

Postgres

ghcr.io/sebadob/rauthy:0.20.1

SQLite

ghcr.io/sebadob/rauthy:0.20.1-lite

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