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 thread comes from the combination of a public client with allowed token refresh, and a stolen or leaked 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 ).