v0.34.3

Changes

org.opencontainers labels

The Rauthy container image does now contain org.opencontainers labels.

#1360

"Register With" Auth Provider

When you have an open registration and configured upstream auth providers, that have auto-onboarding enabled, you will now see a button during the registration saying "or register with {auth provider}".

#1367

Validate User Values during login

You now have the config option to always check user values against the configured requirements during login.

This feature is opt-in. In most scenarios, you will not need it, and if enabled, it will trigger additional database round trips during the login procedure. You may only want to enable it if you made user values requirements stricter for an already existing deployment and absolutely want to force users to update, or if you have an upstream auth provider for which you cannot guarantee that it provides all necessary values. If this check fails, the user will see a popup with an error message and a redirect button to the account dashboard to add the missing values.

[user_values]
# Controls if the value requirements should be re-validated during
# each single login. In most cases, you don't want this. It will
# trigger additional database queries during the login procedure,
# which are unnnecessary in most situations.
# However, if you decide to make the requirements more strict down
# the road, or you use upstream auth providers which may not provide
# all necessary values, you might want to enable this setting.
#
# If a mismatch is found during login, it will be prevented and a
# message will be shown to the user with the information, that some
# information is missing. Only when all required values are set,
# logins will be allowed again.
#
# default: false
# overwritten_by: USER_VALUES_REVALIDATE_DURING_LOGIN
revalidate_during_login = false

#1368

Hide Admin Button

You can now hide the Admin button from the root page in the UI.

[access]
# You can hide the 'Admin' button on the root / landing page for the UI.
# The admin interface is always reachable via `/auth/v1/admin`, and the
# button will only redirect, of course, only when the user is assigned to
# the `rauthy_admin` role. However, if you are hosting some public service,
# you might not want the button to show up there.
#
# default: false
# overwritten by: ADMIN_BUTTON_HIDE
admin_button_hide = false

#1381

Bugfix

• Upstream Auth Providers were shown as login button and in the account dashboard when they were disabled.
  #1366
• With the addition of preferred_username and tz to SCIM users, one database query was forgotten during the update. This could make a SCIM user sync fail.
  #1379

v0.34.2

Changes

Create new ToS improvements

You will now have an additional button in the Admin UI, which lets you create a new ToS from the currently selected one as a template.

When you added a ToS to Rauthy, it would save a pre-rendered and sanitized HTML from the given markdown input, which will then be served to any user that needs to accept the ToS on login. However, this made it impossible to add this new feature. If you wanted to do just a small change, you needed to provide the full ToS from scratch. You can write HTML directly in the markdown editor, but this is of course not the best UX.

This feature will of course not work for any already added, pre-rendered HTML ToS, but it will for all future ones. Rauthy will now save the raw markdown and render it to HTML dynamically.

In addition, content negotiation was added to the /auth/v1/tos/latest endpoint. When the client Accepts text/html, Rauthy will dynamically render a full HTML page instead of returning JSON. This could be used to provide external links to Rauthys ToS.

#1356

Bugfix

• With the rework of login location checks, the refresh tokens for the device_code flow stopped working when using Hiqlite as the database, because of a deserialization issue.
  #1352
• When the preferred_username was set to required, and the registration was open, a misleading error message was displayed, if the username was already taken.
  #1355

v0.34.1

Bugfix

• It was not possible to use /introspect with a client that differs from the one in the access token claims.
  #1349

v0.34.0

Changes

Less login location check noise

The logic behind the "login from new location" emails was reworked. Up until now, the location was compared via user_id + ip. However, if your IP changes quite often, you will receive many of these emails with no real benefit.

To counter this, you will now get a new Cookie during GET /authorize. This cookie will live for 5 years and contain a random String with a "Browser ID". If Rauthy can find such a Browser ID during login, the index for the location check will be user_id + browser_id, which will not generate new warning emails, if your IP changes (as long as you don't delete cookies all the time). The IP will only be used as a fallback in situations, where this Browser ID cannot be found in a cookie.

Note

This change needed a rework of the database table. To make this possible, the old table with login
locations will be dropped and a new one with a proper compound key will be created. This means you
will get new login location emails with this version after the very first login, even when your IP
has not changed.

#1335

Token Revocation

Only because of compatibility issues with Matrix "next-gen auth", Rauthy now provides a token revocation endpoint, which is also published via /.well-known/openid-configuration.

[access]
# Revoke JWT access + refresh tokens if a user does a dedicated logout
# from the account dashboard via the logout button, or when a
# (backchannel) logout is being triggered from a client.
# In most situations, you want your tokens to be able to live longer
# than a session on Rauthy, especially refresh tokens, or access tokens
# issues to headless devices via the `device_code` flow.
#
# !!! CAUTION !!!
# JWT token revocation is a myth and doesn't exist. You can only
# blacklist, but not revoke them, even though that's the official term
# used in the RFC. Token revocation does only work, when a client
# validates tokens against the `/introspection` or `/userinfo`
# endpoints, but they will still be valid, if a client just validates
# via public keys!
#
# The default value of `false` makes the most sense, because token
# revocation is NOT reliable on its own! It only works with the
# "correct" implementation on the client side, which also involves
# a lot more resource and traffic usage!
#
# If a session is being force-deleted or a user is force-logged-out
# via the AdminUI, tokens will always be revoked, which makes the
# most sense.
#
# default: false
# overwritten by: TOKEN_REVOKE_ON_LOGOUT
token_revoke_on_logout = false

# If set to true, tokens issued via the `device_code` flow will be
# revoked during `/logout`.
# These tokens are usually used on headless IoT devices or for CLIs
# on remote servers, and logging these back in can be a lot more
# work than the default logins via browser.
#
# This value will only be respected, if `token_revoke_on_logout` is
# set to `true` as well. Otherwise, tokens will only be revoked
# via the dedicated `recovation_endpoint` or forced logout from an
# admin.
#
# default: false
# overwritten by: TOKEN_REVOKE_DEVICE_TOKENS
token_revoke_device_tokens = false

Caution

JWT Token Revocation is a myth! It does not exist. You cannot revoke JWT tokens by design. Once
they are created and signed, there is no way to revoke them. The only thing you can do is to
blacklist them! Rauthy now keeps track of each single access_token via its jti, and checks
the database during /introspect and /userinfo.

BUT:
Token Revocation does only work, when the tokens are checked against Rauthys API! If a client
validates them via public keys, it is IMPOSSIBLE to "revoke" them. They will be valid until the
exp claim is in the past, which makes the whole term "token revocation" complete nonsense (for
JWT tokens, which are the default in almost all cases these days).

DO NOT RELY ON TOKEN REVOCATION!
This feature only exists for compatibility!

#1328

Custom Root CA for SMTP

You can now provide a custom Root CA certificate for SMTP connections.

[email]
# You can provide a custom Root Certificate in PEM format here,
# which then will be used for SMTP connections.
#
# default: not set
# overwritten by: SMTP_ROOT_CA
root_ca = """
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
"""

#1336

"Password Expired" during login

When you missed the E-Mail notification about a soon expiring password, and you did not renew it in advance, you will now get a warning inside the login form, which notifies you about an expired password.

Beforehand, you would only see "invalid credentials", even though they were correct, only expired. If now the password has expired and the given one matched the expired password, a new reset email will be sent out and you will see the proper message in the login form.

#1337

rauthy Client Name customizable

Usually, if you update anything for the rauthy client via the Admin UI, all values will be reverted with the next restart as part of the anti-lockout rule. However, the Client Name is only a UX improvement. If you update it now, it will excluded from the anti-lockout rule and kept between restarts.

#1309

Additional characters for roles / scopes

Roles and scopes are allowed to have . and UPPERCASE characters from now on. This makes it possible to use namespaced scopes, and the uppercase characters provide compatibility for Element Web / Matrix "next-gen auth".

#1313
#1315

client_id as sub

When you retrieve an access_token via client_credentials flow, the sub claim would be null, because it should only contain End-User IDs by RFC. For some weird reason, there are applications out there expecing the sub claim set to the client_id in such cases, even though this information could be taken from either azp or aud claims.

You now have the possibility to set the sub to the client_id in such cases. Because it's against the RFC and there is a (very tiny) change of misuse, it is opt-in:

[access]
# The `sub` claim should only contain End-User IDs. Therefore, it will
# be `null` for the `client_credentials` flow. However, some applications
# need the `sub` claim to contain the `client_id` in such a case for
# whatever reason (it exists in `azp` / `aud` already anyway). You can
# enable this setting here.
#
# CAUTION:
# Theoretically, it is possible to create a client with an Id that
# matches a user ID (if one with no uppercase chars was generated).
# If this is the case, it is NOT possible to distinguish between
# a user and a client token in such a scenario!
# The chance that an ID for a user without an uppercase char exists
# is almost 0, but it exists.
#
# default: false
# overwritten by: CLIENT_CREDENTIALS_MAP_SUB
client_credentials_map_sub = false

#1334

I18n - Ukrainian Translations

Ukrainian Translations are now available for Email, Common UI and Admin UI.

#1307

Bugfix

• When trying to use Dynamic Clients via an external UI (like e.g. Matrix Element), some CORS preflight checks were failing because of missing headers.
  #1312
  #1314
• The PKCE requirement for Dynamic Clients was inverted and not set as expected for public clients.
  #1316
• jemallocator is incompatible with openbsd.
  #1332
• The @ character was missing in the validation regex for URLs.
  #1330
  #1340
• The text / md editors in the UI sometimes inserted double newlines on Enter.
  #1343

v0.33.4

Changes

timezone for SCIM

The ScimUser now also contains the timezone (with profile scope), which was added in v0.33.0.

#1292

picture + zoneinfo via /userinfo

While fixing the preferred_username bug on the /userinfo endpoint, the picture and zoneinfo were added to the response. There was also a slight rework of the logic to get rid of a few unnecessary memory allocations.

#1291

Bugfix

• The preferred_username was not set correctly on the /userinfo endpoint. It still had the old behavior (pre v0.33) and it always contained the email.
  #1291
• With the added support for 16k / 64k kernels on arm64, a conflict for the MALLOC_CONF was discovered. To resolve it, the value is not set during build time anymore, but was added as an ENV var with a default value to the final release container. It can be overwritten as it was the case before.
  #1293

v0.33.3

Changes

Default kernel page size on arm64

Support for kernel page sizes up to 64K on arm64 was added. This makes it possible to run on e.g. Raspberry Pi 5's default kernel, and other 64k kernels. This might increase the memory usage on 4k arm64 devices a tiny bit, but should improve efficiency and performance on 64k kernels.

This is for arm64 only, since x86_64 has fixed 4k page sizes.

#1288

v0.33.2

Changes

Updated I18n

Translations for zh / zhhans have been updated, and zh is available for the Admin UI now as well.

#1278
#1279

Hiqlite trigger backup via API

While fixing the "no local backup with no S3 config" bug mentioned below in Hiqlite, a small feature was added. It is now possible to trigger the creation of a backup manually via direct API call, in addition to using the Rauthy Admin UI or relying on the cron job. It is a simple POST request to the Hiqlite API (port 8200 by default) using the API secret, like so:

curl -i -XPOST -H 'X-API-SECRET: SuperSecureSecret1337' localhost:8200/backup

Bugfixes

• Hiqlite had a bug where the backup cron job was not started if no S3 config was given. It was bumped to the latest version which includes a fix.
• The UI had some smaller CSS issues here and there after the recent updates.
  #1283

v0.33.1

Bugfix

• The new feature "Rauthy Logo as client fallback" from v0.33.0 was working fine for the branding page, but not during /authorize.
  #1276

v0.33.0

Breaking

JWKS rotate / cleanup scheduler

The JWKS rotate scheduler was not started on some of the last versions when it should have. For this reason, depending on which version you were running and for how long, the cleanup scheduler might clean up "too much". It is advisable to trigger a manual JWKS rotation before doing the upgrade:

Admin UI -> Config -> JWKS -> Rotate Keys

At least if you see errors after the upgrade with something like "kid not found" when trying to fetch public keys for validation, you need to rotate manually once.

preferred_username in Tokens

The preferred_username was always added to both access_token and id_token and it always contained the same value as the email claim. This it NOT the case anymore! This value is configurable now. To match the OIDC spec, it will never be added to the access_token anymore, and only exist in the id_token if the client requested the profile scope during login. The value of this claim depends on your configuration. For more details, check the "preferred_username and tz" changes below.

Because of these changes, the email will not show up as the username in the response from the OAuth2 /introspect endpoint as well.

Note: If you are using the rauthy-client, make sure to upgrade it to 0.11 beforehand.

User Request and Response API data

The user values are much more configurable now (see in changes below). At the same time, the given_name is now always optional in responses from the API. The necessary values during user registration, if you have an open endpoint and use direct API requests from somewhere else, have changed as well. They now also depend on your configuration.

If you don't change anything in the new [user_values] section, you will not experience any breaking changes for direct API requests.

Changes

AuthorizedKeys for PAM users

If a user is linked to an existing PAM user, and the config allows it, users can upload their own public keys. A server can then make use of the AuthorizedKeysCommand via the sshd_config and resolve these public keys dynamically:

AuthorizedKeysCommand
   Specifies a program to be used to look up the user's
   public keys.  The program must be owned by root, not
   writable by group or others and specified by an absolute
   path.  Arguments to AuthorizedKeysCommand accept the
   tokens described in the “TOKENS” section.  If no arguments
   are specified then the username of the target user is
   used.

   The program should produce on standard output zero or more
   lines of authorized_keys output (see “AUTHORIZED_KEYS” in
   sshd(8)).  AuthorizedKeysCommand is tried after the usual
   AuthorizedKeysFile files and will not be executed if a
   matching key is found there.  By default, no
   AuthorizedKeysCommand is run.

rauthy-pam-nss was updated and can work with this new feature. You need to update to v0.2.0 for compatibility.

You will have the following new config options:

[pam.authorized_keys]

# If set to `true`, a user with a linked PAM user can upload
# public SSH keys via the account dashboard. This is disabled
# by default, because the auto-expiring PAM user passwords are
# the safer option.
#
# default: true
# overwritten by: PAM_SSH_AUTHORIZED_KEYS_ENABLE
authorized_keys_enable = true

# By default, even though these are "public" keys, the endpoint
# to retrieve them requires authentication. This will be a `basic"
# `Authentication` header in the form of `host_id:host_secret` of
# any valid PAM host configured on Rauthy.
# If you set it to `false`, the endpoint will be publicly available.
# This is fine in the sense that you cannot leak any keys (they are
# public keys anyway), but the endpoint could be abused for username
# enumeration. Depending on the `include_comments` settings below,
# you might even leak some more information that is not strictly
# sensitive, but could be abused in some other way.
#
# default: true
# overwritten by: PAM_SSH_AUTH_REQUIRED
auth_required = true

# By default, SSH keys that have expired because of
# `forced_key_expiry_days` below will be added to an internal
# blacklist. This blacklist will be checked upon key add to
# make sure keys were actually rotated and that not an old key
# is added again.
#
# default: true
# overwritten by: PAM_SSH_BLACKLIST_SSH_KEYS
blacklist_used_keys = true

# Configure the days after which blacklisted SSH keys will be
# cleaned up.
#
# default: 730
# overwritten by: PAM_SSH_BLACKLIST_CLEANUP_DAYS
blacklist_cleanup_days = 730

# You can include comments in the public response for the
# `authorized_keys` for each user. This can be helpful for
# debugging, but should generally be disabled to not
# disclose any possibly somewhat "internal" information.
#
# default: true
# overwritten by: PAM_SSH_INCLUDE_COMMENTS
include_comments = true

# You can enforce an SSH key expiry in days. After this time,
# users must generate new keys. This enforces a key rotation
# with is usually overlooked especially for SSH keys.
# Set to `0` to disable the forced expiry.
#
# default: 365
# overwritten by: PAM_SSH_KEY_EXP_DAYS
forced_key_expiry_days = 365

#1249
#1250
#1253

preferred_username and tz

The custom user values have been expanded. Each user can now provide a preferred_username and a tz (timezone) via the account dashboard. The default timezone will always be UTC, just like it was up until this version. The preferred_username behavior depends on some new configuration values. In addition to that, the requirements of all other already existing values has more config options as well. Everything that is required will also be requested during the initial registration, if you have an open registration endpoint.

Because we have these new values, they will also show up in the id_token if the profile scope was requested. Until now, the preferred_username was always existing and simply set to the email. However, this has the potential to produce issues in downstream clients, if they don't handle the preferred_username properly and require some specific value (which they really should not ...). If the user has anything else than UTC or Etc/UTC configured as timezone, the zoneinfo claim will be added to the id_token as well.

CAUTION: If your client does not request the profile scope during login, the preferred_username will NOT be set to the email like it was the case up until this version!

These are the new config options:

[user_values]

# In this section, you can configure the requirements for different
# user values to adjust them to your needs. The `preferred_username`
# as a special value provide some additional options.
# The `email` is and always will be mandatory.
#
# A value of `hidden` will only hide these values for normal users
# in the account dashboard. An admin will still see all values.
#
# You can set one of the following values:
# - required
# - optional
# - hidden

# default: 'required'
given_name = 'required'
# default: 'optional'
family_name = 'optional'
# default: 'optional'
birthdate = 'optional'
# default: 'optional'
street = 'optional'
# default: 'optional'
zip = 'optional'
# default: 'optional'
city = 'optional'
# default: 'optional'
country = 'optional'
# default: 'optional'
phone = 'optional'
# default: 'optional'
tz = 'optional'

[user_values.preferred_username]

# If the `preferred_username` is not set for a given user, the
# `email` will be used as a fallback. This can happen, if it is
# not set to `required`, or if you had it optional before and
# then changed it, while the user may have not updated it yet
# according to the new policy.
#
# one of: required, optional, hidden
# default: 'optional'
preferred_username = 'optional'

# The `preferred_username` is an unstable claim by the OIDC RFC.
# This means it MUST NOT be trusted to be unique, be a stable
# map / uid for a user, or anything like that. It is "just
# another value" and should be treated like that.
#
# However, `preferred_username`s from Rauthy will always be
# guaranteed to be unique. You can define if these usernames
# are immutable once they are set, which is the default, or if
# users can change them freely at any time.
#
# default: true
immutable = true

# Provide an array of blacklisted names.
#
# CAUTION: Provide all these names as lowercase! The value
#  submitted via API will be converted to lowercase and
#  then compared to each entry in this list.
#
# default: ['admin', 'administrator', 'root']
blacklist = ['admin', 'administrator', 'root']

# You can define the validation regex / pattern.
#
# The `pattern_html` it will be sent to the frontend as a
# String value dynamically. It must be formatted in a way,
# that it will work as a
# [`pattern` attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/pattern)
# after the conversion. If you are unsure if it works, check
# your developer tools console. You will see an error log
# if the conversion fails.
# NOTE: These are NOT Javascript regexes!
#
# By default, the validation matches the Linux username regex,
# but you may want to increase the minimum characters for
# instance.
#
# default: '^[a-zA-Z0-9][a-zA-Z0-9-.]*[a-zA-Z0-9]$'
regex_rust = '^[a-zA-Z0-9][a-zA-Z0-9-.]*[a-zA-Z0-9]$'
# default: '^[a-z][a-z0-9_\-]{1,61}$'
pattern_html = '^[a-z][a-z0-9_\-]{1,61}$'

# If a user does not have a `preferred_username`, the `email`
# can be used as a fallback value for the id token.
#
# default: true
email_fallback = true

Terms of Service

It...

v0.32.6

Bugfix

• In hiqlite as an external dependency, it was possible to get into a situation where the WAL cleanup of not anymore needed logs / files was not working as expected. This could lead to an endlessly filling up volume. This version bumps hiqlite to the latest, fixed version. With the next snapshot creation for existing instances (every 10k Raft logs), all old WAL files will be cleaned up.
  #1233