v0.36.2

Security

There were 2 reachable panics in certain situations. Especially in one case it was easy to abuse it for an unauthenticated DoS if you had a public client with enabled token refresh. A security advisory with more information will be released in the upcoming days.

v0.36.1

Security

There was a security issue with Moderate severity during token refresh under some circumstances that allows cross-client token minting and identity/scope confusion during token refresh. You should do a timely update or at least make sure you are not vulnerable. If you run the default config, you should be good.

If you have public clients with the refresh_token flow enabled and either you have configured dynamic_clients.enable = true + dynamic_clients.reg_token not set or ephemeral_clients.enabled = true + ephemeral_clients.allowed_flows contains refresh_token, it
might be possible to abuse an issue. There is a slight chance to make it work without ephemeral or dynamic clients, but that is out of Rauthys control. The main threat comes from the combination of a public client with allowed token refresh, and a stolen or leaked valid refresh token.

An advisory and CVE / PoC will be made public at a later point.

Changes

Per-Client Favicons

Client branding now supports a dedicated browser favicon for each client, independently of the login logo. Favicons can be uploaded, previewed, and removed from the Admin UI.

#1653

Session MFA Upgrade after Passkey Registration

Registering a Passkey from the Account dashboard upgrades the current session to MFA now. Before, is_mfa stayed false until the next login, which meant a fresh admin account that just enrolled its first Passkey was still rejected by admin_force_mfa and had to log out and back in. The Account dashboard also updates the MFA indicator directly after registering or deleting a Passkey instead of only after a manual page reload.

#1649

Token Exchange (RFC 8693)

Rauthy supports the RFC 8693 token exchange now, via the urn:ietf:params:oauth:grant-type:token-exchange grant on the existing token endpoint. It lets a service trade an access token it received for one that is scoped to a downstream service, instead of forwarding a token that was never minted for that target.

Both impersonation and delegation are supported. With an actor_token, the exchanged token carries an act claim naming the acting party, so a resource server can tell "A acting for B" apart from "B"; a delegation chain stays nested inside it.

The exchange is deny-by-default and needs two things on the exchanging client: token_exchange in its flows_enabled, and the requested target in its allowed_resources, which is the same allow-list the RFC 8707 resource indicators use. Only confidential clients may exchange.

Rauthy only accepts access tokens as subject_token / actor_token, and only ever issues an access token in return. An exchanged token deliberately never comes with a refresh token. may_act is not supported yet.

#1652

RFC 8414 Metadata Endpoints

Rauthy now correctly serves the .well-known metadata documents under additional endpoints matching the RRFC 8414. This was necessary for CIMD discovery that's used by e.g. Claude.ai.

#1656

Opt-in to ignore unknown grant-types from ephemeral clients

This is a fix for clients relying on CIMD (like AI agents) when you don't have control over the client documents, and they include unknown / invalid grant types, even when they are unused.

[ephemeral_clients]
# A dynamic client registration is always rejected when it advertises a grant
# type Rauthy does not support. Some spec-valid CIMD clients (e.g. claude.ai)
# advertise an unsupported grant (`urn:ietf:params:oauth:grant-type:jwt-bearer`)
# in their metadata document without ever using it, which would otherwise cause
# the whole document to be rejected. Setting this to `true` lets an ephemeral
# (CIMD) client document through by sanitizing - stripping - the unsupported
# grant types instead of rejecting it.
#
# This applies ONLY to ephemeral clients. Dynamic client registration (DCR) and
# admin-managed clients always keep rejecting unknown grant types.
#
# default: false
# overwritten by: EPHEMERAL_CLIENTS_IGNORE_UNKNOWN_AUTH_FLOWS
ignore_unknown_auth_flows = false

#1658

RFC 8252 for localhost callbacks

Rauthy uses a more-strict requirement for redirect_uris back to localhost. If you want to match any port, you need to specifically allow it using the glob pattern with e.g. http://localhost:*. However, CIMD clients do not know this and rely on RFC 8252 which allows any port for localhost. This is the standard, but less secure. You can now opt-in to it:

[access]
# If set to `true`, loopback redirect URIs (to `localhost`, `127.0.0.1`
# or `[::1]`) will match on any port, as required by RFC 8252 section 7.3
# for native / CLI apps that bind an ephemeral loopback port at runtime.
# Both the port-less form and an explicit `*` wildcard are accepted for
# `localhost` when this is enabled.
#
# This only applies to dynamic and ephemeral clients. Static clients
# always require an exact match or an explicit `*` wildcard, even with
# this option set, because an admin has full control over their config.
#
# Only enable this if you need it, e.g. an MCP client whose loopback
# redirect port is not known in advance and cannot be pre-registered.
# It is `false` by default to keep redirect matching as strict as
# possible out of the box.
#
# default: false
# overwritten by: RFC_8252_ENABLE
rfc_8252_enable = false

#1621

preferred_username during User Registration

It is now possible to provide a preferred_username during the user registration when using API Keys. This gets rid of an additional round-trip that was necessary when working with the API instead of the UI.

#1640

Relaxed regex for Client Names

Client names are now allowed to also contain ( and ).

#1621

Bugfix

• The sub claim is now omitted from tokens if it is null anyway.
  #1655
• The resource claim was dropped during UI-initiated, immediate session / login refreshes.
  #1657
• A callback for an upstream auth provider login is deleted as soon as it has been validated now. Before, only a failed state, XSRF token or PKCE verifier check deleted it. A callback that passed all three stayed in the cache until its 300 second TTL ran out, whether the login then succeeded or failed. This also makes the behaviour match what the function documented all along.
  #1664
• user.last_login was wrongly updated on token refreshes.
  #1659

v0.36.0

Breaking

Technically, this is not a breaking change, but it might be for you. The config parser now has an additional validation for left-over, unknown keys after parsing has finished. If any data is left, Rauthy will panic. This makes sure you cannot have typos or data in your config that does nothing at all. This means this might be a somewhat "breaking" change if you have invalid or additional data in your config. Just be prepared to adjust your config when you update.

#1587

Security

In some scenarios, when you knew the internal User ID of another user, and you had a similar Password / MFA configuration, it was possible to get mixed session states during Webauthn Ceremony Finish. It was e.g. possible to reset the "last login" timestamp or to trigger a "Login from new location" message for another user.

#1625

Changes

Delegated Group Admins

You can now delegate user management to non-admins via group-scoped roles. A role named rauthy_admin:<group> makes its holders a group admin for the matching group(s): an exact match by default, a trailing * for a prefix glob, and rauthy_admin:* for all groups.

A group admin can manage users that are members of a group it manages (create, edit profile, toggle enabled, manage in-scope group memberships, reset MFA, reset or set a password, manage the profile picture, view / invalidate sessions, and send a bulk E-Mail scoped to one of its managed groups) and gets a read-only view of Sessions, Events and the Blacklist for debugging. It can never modify roles, delete users, send unscoped bulk E-Mails, manage other admins, or touch any non-user administration. This is non-breaking unless you already use a custom role starting with rauthy_admin:; such roles are logged on startup.

#1538

Custom Claims on client_credentials Tokens

A client can now carry admin-defined custom claims. You can set a JSON object on a Client in the Admin UI (or via the management API), which is emitted into the access token of the client_credentials flow. This lets machine clients carry self-describing claims (workload identity, tenant id, deployment profile, ...) without the resource server having to look anything up
by client_id.

By default, the claims are nested under the custom claim; an opt-in claims_at_root flag emits them at the token root instead (a collision with a reserved claim fails token issuance). The value must be a JSON object and is capped at 1024 serialized characters. Dynamic and ephemeral clients cannot set their own claims.

#1604

Resource Indicators (RFC 8707)

Rauthy now supports RFC 8707 resource indicators. Clients may send a resource parameter on the authorization and token requests (for the authorization_code, client_credentials and refresh_token grants) to request an audience-restricted access token. The requested resource is validated against a new per-client allowed_resources allow-list (empty means deny, returning invalid_target), and a second new per-client field default_aud lets you always add fixed audiences to a client's tokens without a request parameter, e.g. for clients that cannot send a resource.

Ephemeral clients deny resource requests by default unless ephemeral_clients.danger_allow_unvalidated_resource is enabled or the client document declares its own allowed_resources.

[ephemeral_clients]
# RFC 8707: when an ephemeral client document declares no `allowed_resources`,
# a requested `resource` is rejected by default. Setting this to `true` lets such
# clients request any resource indicator.
#
# CAUTION: only enable this if you know exactly what you are doing and have a good
# reason. It can lead to an easy privilege escalation, because an ephemeral client
# could then mint tokens for an arbitrary audience.
#
# default: false
# overwritten by: EPHEMERAL_CLIENTS_DANGER_ALLOW_UNVALIDATED_RESOURCE
danger_allow_unvalidated_resource = false

As part of this, the aud claim is now emitted as a JSON array when a token carries two or more audiences, and stays a single string otherwise. This also fixes the solid_aud case for Solid-OIDC ephemeral clients, which previously emitted a string that merely looked like an array.

#1562

Secrets from file

You now have a 3rd option to provide secrets. The first is to inline them in the config, which makes the config itself a secret. The 2nd is to provide them as ENV vars, which you should avoid if possible, but sometimes it's the only way. The new option now is from an additional secrets file.

By default, Rauthy will look for a ./secrets.toml. You can overwrite the path via CLI when serveing with the -s, --secrets-file <SECRETS_FILE> option.

You can only put real secrets inside this file. Anything additional will trigger an error. By default, these values are ignored unless you explicitly configure them to be read from this file. To do so, instead of providing a secrets inside the config directly, you can set the values to

"$SECRETS"

This value is case-sensitive. If set to any of the secrets, the config parser expects the value to exist in the secrets toml file.

As mentioned already, this file must have the exact same sections and variable names as the secret in the main config. For instance, if you have database.pg_password in the config, and you set the value to "$SECRETS", you must provide a database.pg_password in the secrets toml.

You can optionally read the following secrets in this way:

[cluster]
secret_raft = ''
secret_api = ''
s3_key = ''
s3_secret = ''
password_dashboard = ''

[database]
pg_user = ''
pg_password = ''

[dynamic_clients]
reg_token = ''

[email]
smtp_username = ''
smtp_password = ''
xoauth_client_id = ''
xoauth_client_secret = ''

[encryption]
keys = ['']
key_active = ''

[events]
matrix_user_id = ''
matrix_access_token = ''
matrix_user_password = ''
slack_webhook = ''

[geolocation]
maxmind_account_id = ''
maxmind_license_key = ''

[user_pictures]
s3_key = ''
s3_secret = ''

The encryption.keys is an exception here. The parser expects an array instead of a single String. You can read them from secrets with by setting: keys = ['$SECRETS']

#1623

PAM User custom home

You can now set a custom home directory for PAM users. To make this work end-to-end, an update of the rauthy-pam-nss service is necessary as well.

#1592

API Keys Advanced Bootstrap

API Keys can now be bootstrapped during advanced bootstrapping from JSON files.

#1585

Advanced Bootstrapping

Secrets can now be auto-generated during bootstrapping from files. They are then saved inside an encrypted container on disk, which you can read via the Rauthy CLI afterwards. For detailed information, check the book.

#1610

API Keys can manage other API Keys

Even though not being recommended, you can now allow an API key to manage other API keys.

#1609

Pattern hint for preferred_username

You can now specify a custom pattern hint for the pattern validation in the UI for the Preferred Username.

[user_values.preferred_username]
# Configure a hint that will be shown to the user on pattern
# mismatch.
#
# default: not set
pattern_hint = 'Linux-compatible Username'

#1624

Stricter Client ID validation

Client IDs for manually managed clients are now validated against the stricter pattern ^[a-zA-Z0-9._\-]{2,256}$, which matches the existing Admin UI restriction. This applies when creating a client via the API and when bootstrapping clients from JSON files. Ephemeral clients are unaffected and may still use a full URI as their ID.

Previously, the backend accepted URI-shaped IDs on these paths, even though such a client cannot be managed in the Admin UI and behaves completely differently depending on whether ephemeral clients are enabled. Existing clients with such an ID keep working and can still be updated, since the ID for an update is taken from the URL path; only creating or bootstrapping a new client with such an ID is now rejected.

As part of this, the redundant id field was removed from the client update request body. It was a leftover from an older API version: on update the ID is always taken from the URL path and could never be changed, so the field had no effect, and any id still sent in the body is now ignored.

#1605

Validate Config

The CLI can now validate an existing Rauthy Config:

./rauthy validate-config -p config.toml

#1588

Hiqlite v0.14.0

Hiqlite was updated to v0.14.0.

You can now rate-limit all Raft write actions. These are things like cache PUT or e.g. execute queries. This limit does not affect read actions, since they are local and do not travel through the network. With this rate-limiting, if tuned properly for your deployment, you can guarantee that you never saturate your disk, and therefore can never get in a situation where you overwhelm the cluster, no matter how high requests might spike.

Just as a very rough guideline: When you only write tiny queries that INSERT 3 columns per row, and you limit the Raft to 50.000 requests / s, your disk already writes 350+ MB/s. How you want to tune thi...

v0.35.2

Security

This version bumps several 3rd party dependencies to fix CVEs in them. A timely update is advised.

Changes

preferred_username in forward auth headers

You now have additional ENV vars to overwrite config options for the preferred_username:

[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'
# overwritten_by: PREFERRED_USERNAME
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
# overwritten_by: PREFERRED_USERNAME_IMMUTABLE
immutable = true

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

It is now also possible to include the preferred_username in forward auth headers:

[auth_headers]

# If additionally, the preferred username header shuold be enabled.
# This requires an additional DB lookup each time and is therefore
# disabled by default.
#
# default: false
# overwritten by: AUTH_HEADERS_ENABLE_PREF_USERNAME
enable_pref_username = false

# default: x-forwarded-user-pref-username
# overwritten by: AUTH_HEADER_PREF_USERNAME
preferred_username = 'x-forwarded-user-pref-username'

#1565
#1566

Rauthy as AS for MCP custom connectors

This is a part of making Rauthy work as AS for MCP custom connectors. Most of the work was already done. Now CIMD support is advertised in the openid-configuration and there is a additional alias /.well-known/oauth-authorization-server for the openid-configuration. In addition, the email_verified claim is no added to the access_token when the email scope is requested.

#1560
#1561

nonce for device_code flow

When using the device_code flow, even though it is not part of the RFC, it is now possible to provide an optional nonce when fetching a token.

#1549

/userinfo fallback for Upstream Providers

If an upstream auth provider does not return an id_token with the minimal required information, it will be ignored and the /userinfo will be fetched using the access_token. This increases compatibility.

Client ID validation in UI

The API accepts Client IDs as full URIs. This is mandatory to make ephemeral clients work.

However, with a change a while ago, where UPPERCASE characters were added to the validation regex for new Client IDs, I accidentally allowed full URI IDs in the UI. This is not an issue on it's own, because the API works perfectly fine with it. The issue with this is:

1. It was possible to theoretically create conflicts manually with clients created by the backend during DCR with the dyn$ prefix.
2. It was technically allowed to provide a URI as Client ID that made the UI fail, because it does not URL encode Client IDs during API requests. It could be allowed and fixed easily, but it should never be necessary in the first place. If you add a Client with a URI as ID to the DB, Rauthy would lookup the whole configuration dynamically, because it would be treated as an ephemeral client.

To fix these misleading issues, the regex was restricted a lot more again. It is now the following:

^[a-zA-Z0-9._\-]{2,256}$

This still allows for CamelCasedClientIDs, and it keeps all characters in a URL-safe range.

#1572

Bugfix

• The config file generator from the CLI produced output with a missing quote for nodes.
  #1545
• The suspicious request scan detection was flagging requests to sitemap.xml as a false-positive.
• With some SMTP servers it was possible to reach a panic in the mailer when an invalid email was given.
  #1557

v0.35.1

Changes

Request Duration in Logs

The access logs in the console now contain the total requests duration. This came with a small change when you need to debug something. The access log is not the first thing you will see for a specific request, but actually the last thing. We can only know the total duration at the end of the request, not at the beginning. This is just something to keep in mind.

#1525

Connect to Postgres via UDS

You can now connect to Postgres via UDS. You can specify a path to the socket for the pg_host config var. In addition, you can now also provide a custom root CA for Postgress connections, and you can specifically disable, require or prefer TLS.

[database]
# If you set `hiqlite = false` and want to use Postgres as your
# database, you need to set the following variables.
# These will be ignored as long as `hiqlite = true`.
#
# overwritten by: PG_HOST
pg_host = '/var/run/postgresql'
# default: 5432
# overwritten by: PG_PORT
#pg_port = 5432
# overwritten by: PG_USER
pg_user = 'rauthy'
# overwritten by: PG_PASSWORD
pg_password = '123SuperSafe'
# default: rauthy
# overwritten by: PG_DB_NAME
pg_db_name = 'rauthy'

# You can specifically set the TLS mode for Postgres connections.
# The default 'prefer' will try TLS first and fall back to plain
# connections once it fails. However, if you connect via UDS,
# the fallback will not work, and you max have to disable it all
# together.
#
# possible values: disable, prefer, require
# default: 'prefer'
# overwritten by: PG_TLS
pg_tls = 'require'

# Provide a custom root CA for your Postgres connections.
#
# overwritten by: PG_TLS_ROOT_CA
pg_tls_root_ca = """
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
"""

#1527

Additional i18n translations

There are 2 additional i18n translations: Russian (ru) and French (fr)

#1503
#1523

Optional Account Redirect

You can now configure an optional redirect from /auth/v1/ to /auth/v1/account.

[access]
# If set to `true`, requests to `/auth/v1/` will be redirected to
# `/auth/v1/account` (the account dashboard). This is useful if you want
# users to land directly on their account page when visiting the root URL.
#
# default: false
# overwritten by: REDIRECT_ROOT_TO_ACCOUNT
redirect_root_to_account = true

#1509

Hidden Password Input

When the login form is in the first stage where you only should enter the email, there is now a hidden password input to help password managers detecting and auto-filling the login form better in some cases.

#1524

Book Update

The Rauthy book got ouf of sync in a few sections, and it did not mention some of the latest new features. It was updated in lots of places.

#1529

Bugfix

• The prompt param during /authorize was not accepting multiple values
  #1500
• During an internal code rework, the ko and zh translations for the password E-Mails got switched around.
  #1526
• When deleting the very last Passkey for a user, and when you were using Postgres, there was a foreign key constraint which made it fail and return a DB error.
  #1528

v0.35.0

Breaking

The Rauthy Issuer was changed!

Before, it was https://iam.example.com/auth/v1. Now it will be https://iam.example.com/auth/v1/, with the trailing / appended. This was a somewhat necessary change to do before v1.0.0. There are clients out there, which do not check for a trailing /, and only use the issuer URL as a base to construct the openid-configuration URL for instance. This can fail, as the /v1 beforehand was seen as something like a filename, and therefore stripped from the "base URL". This leads to an invalid URL for the openid-configuration, and therefore to incompatibility. To improve this situation, it was decided to change the Issuer and always append the / in the end.

This single character comes with a huge impact!

You will need to update your clients! Their token validation will fail, when they validate for the old issuer without the trailing /. This means that this update will require downtime!. Not on Rauthy's side, but it will most probably make client logins unavailable until they were updated.

For instance, when I tested with a forgejo instance which used auto-discovery, all it needed was a restart to trigger a fresh lookup and clear caches. For another Harbor instance however, I needed to log in and manually update the issuer, and append the /. This has lead to a weird error (which was probably a bug in Harbor), that the user under the hood was now not linked to the existing provider anymore. This was very unexpected, as it was only updated, never deleted. The fix was to delete all OIDC users and let them do a fresh onboarding with the next login.

When you use the rauthy-client, I advise you to update to v0.13 BEFORE updating Rauthy. This version will be compatible with Rauthy v0.35 and the old ones at the same time, as it will accept the issuer with and without the trailing /. This means with the rauthy-client:0.13+, you will be able to do the Rauthy upgrade without any downtime.

So sum this up:

• If you use the rauthy-client, upgrade to 0.13 beforehand, which means no downtime.
• If you have an application with auto-discovery, it most probably only needs a restart or cache
  clear, if available.
• If you have a static configuration, you need to update the issuer and append the / in the end.

Note

This is probably the last bigger breaking change before releasing Rauthy v1.0.0.

Custom Attributes Values

The custom user attributes were taking every value a just a String, even though the UI said "JSON Value". The backend parsed them as JSON Values, but since the UI always sent Strings, they were all JSON Strings, which is not that helpful. This version changes this behavior. There is no equivalent for Rusts serde_json::Value in JS, but a custom parsing function was added to the UI. This now makes it possible to actually parse separate, typed JSON values.

This means when you had set custom attributes before, they were returned like this:

{
  "custom": {
    "str": "some string",
    "arr": "[1, 2, 3]",
    "num": "1337",
    "obj": "{\"key\": \"value\", \"key2\": 123}"
  }
}

Now instead, since the UI can parse and type the input properly, you will get:

{
  "custom": {
    "arr": [
      1,
      2,
      3
    ],
    "num": 1337,
    "obj": {
      "key": "value",
      "key2": 123
    },
    "str": "some string"
  }
}

Depending on how you currently extract custom attributes, this may be a breaking change for you.

#1491

Changes

Global KV Store

Sometimes, you need a simple place to store e.g. additional policies or things like that, or maybe you need some additional information about your Rauthy instance, or some clients, and you want to have all your authn / authz related information in one place. For that reason, Rauthy now brings a global KV store.

You can define multiple, independent namespaces. Each namespace is private by default but can optionally allow public access. You can add additional Access Keys for each namespace. Key / Value pairs can be added without any prior definition necessary. The value can be any valid JSON value, and it therefore typed automatically. You can add:

• number
• bool
• string
• array
• objects

They will be auto-detected and returned properly by the API. You can find it in the Admin UI navigation on the left side.

Tip

While implementing the KV store, custom metadata JSON fields have been added to roles and groups as well.

#1491

Credential Stuffing Detection

Rauthy was already detecting brute-force attempts for a user. When multiple passwords were wrong, the timeout between retries would be artificially increased. Now it can also detect credential stuffing over multiple accounts. How it works is pretty simple:

• If a user fails doing a login, the username + password will be sent into the cred stuff detector.
• The detector will create a hash(username + password) and store it in the cache.
• The duration will be the so called scan_window, which can be configured.
• If the length of unique hashes exceeds the configured threshold, the IP will be automatically blacklisted.
• When any new failure event comes in and there are already hashes collected, then scan_window will NOT expire depending on the first add, but the timer will reset with each event.

[cred_stuff_detection]
## This section contains values for the credential stuffing
## detection algorithm. In most cases the defaults should be
## fine.

# The duration in seconds for how long an IP will be
# blacklisted after it was considered harmful, doing
# credential stuffing.
#
# default: 86400
# overwritten by: CRED_STUFF_BLACKLIST_DUR
blacklist_duration = 86400

# The threshold for username / password combinations. When
# this is reached within the `scan_window` the IP will be
# blacklisted and a new warning Event will be fired.
#
# default: 15
# overwritten by: CRED_STUFF_BLACKLIST_THRES
blacklist_threshold = 15

# The time in seconds within the detector should operate.
# Whenever either a non-existing email or a email with a
# wrong password is sent, the combination of both will be
# hashed and stored (in-memory) for the duration of this
# value. If any new event happens within this time frame,
# the new hash will be stored as well, and then timer will
# reset to `scan_window` again. Only if not a single event
# happens during the whole duration, the values will be
# evicted.
#
# Keep in mind, that when the `scan_window` is bigger than
# `blacklist_duration`, a single false login may be enough
# to blacklist an IP again, after it was removed from the
# blacklist.
#
# default: 10800
# overwritten by: CRED_STUFF_SCAN_WINDOW
scan_window = 10800

There is also a new event you can configure the level for:

[events]
# The level for the generated Event after an IP has
# been considered harmful, doing credential stuffing.
#
# default: warning
# overwritten by: EVENT_LEVEL_CRED_STUFF
level_cred_stuff = 'warning'

#1488

User Enumeration Prevention

When you had an open user registration, it was a known issue that it had the potential for username enumeration because Rauthy simply behaved like almost all other applications. However, this is mitigated now. When a user registers and the email exists already, the response will always be 'success'. If it existed before, however, the user will receive a notification email about it with a link to request a password reset.

#1487

Upgraded to hiqlite-v0.13

The underlying hiqlite was upgraded to v0.13. This version includes a small throughput improvement of ~12%. Apart from that, it comes with optimized and much improved macros, which do not only boost performance (as seen on the 12%), but they also provide better future maintenance. Many manual DB deserialization impls are now auto-generated. The same macro was created for Postgres types as well to have the exact same behavior. Apart from maybe the small performance improvement, the end user will not really notice anything about it though. It's most about future maintenance, stability and improved DX.

Another feature that was added with this version is auto-encrypted in-cluster TLS traffic. If you want to follow a zero trust philosophy, and you don't have something like a service mesh with auto mTLS in place already, you don't need to manage TLS certificates for hiqlite cluster traffic manually anymore. You have a new config variable to make it maintenance-free:

[cluster]
# The `tls_auto_certificates` will generate self-signed TLS
# certificates for internal Raft and API traffic. Clients will
# simply not validate the certificates for ease of use because
# they don't have to. They do a 3-way handshake anyway, which
# validates both client and server without the secret ever being
# sent over the network.
#
# If you specify specific certificates with either `tls_raft_*` or
# `tls_api_*`, they will be used instead.
#
# default: false
# overwritten by: HQL_TLS_AUTO_CERTS
tls_auto_certificates = false

#1481

The Binary has a CLI

The rauthy binary now has a CLI. This makes it possible to not only specify a custom path to your config file, but it also provides additional utility. You can use it to generate new encryption keys, or to generate a complete config to get you started. More documentation about it will be added to the book in the future. The tl;dr for now is: You start the Server with rauthy serve now, and with the -c option, you can select a custom config file path:

[#1481](https://github.com/sebadob...

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