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 defualt.
#
# 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 fetching tokens via 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