github sebadob/rauthy v0.22.0

latest releases: v0.25.0, v0.24.1, v0.24.0...
5 months ago

Breaking

There is one breaking change, which could not have been avoided.
Because of a complete rewrite of the logic how custom client logos (uploaded via
Admin UI -> Clients -> Client Config -> Branding), you will loose custom logos uploaded in the past for a client.
The reason is pretty simple. Just take a look at Auto Image Optimization below.

Apart from this, quite a few small internal improvements have been made to make life easier for developers and new
contributors. These changes are not listed in the release notes.

Changes

Upstream Auth Providers

Rauthy v0.22.0 brings (beta) support for upstream authentication providers.
This is a huge thing. It will basically allow you to set up things like Sign In with Github into Rauthy. You could use
your Github account for signup and login, and manage custom groups, scopes, and so on for the users on Rauthy. This
simplifies the whole onboarding and login for normal users a lot.

You can add as many auth providers as you like. They are not statically configured, but actually configurable via the
Admin UI. A user account can only be bound to one auth provider though for security reasons. Additionally, when a user
already exists inside Rauthy's DB, was not linked to an upstream provider and then tries a login but produces an email
conflict, the login will be rejected. It must be handled this way, because Rauthy can not know for sure, if the upstream
email was actually been verified. If this is not the case, simply accepting this login could lead to account takeover,
which is why this will not allow the user to login in that case.
The only absolutely mandatory information, that Rauthy needs from an upstream provider, is an email claim in either
the id_token or as response from the userinfo endpoint. If it cannot find any name / given_name / family_name,
it will simply insert N/A as values there. The user will get a warning on his next values update to provide that
information.

The supported features (so far) are:

  • auto OpenID Connect metadata discovery
  • accept invalid TLS certs for upstream clients, for instance inside self-hosted environments
  • provide a root certificate for an upstream client for the same reason as above
  • choose a template for the config (currently Google and Github exist)
  • fully customized endpoint configuration if the provider does not support auto-lookup
  • optional mfa claim mapping by providing a json parse regex:
    If the upstream provider returns information about if the user has actually done at least a 2FA sign in, Rauthy can
    extract this information dynamically from the returned JSON. For instance, Rauthy itself will add an amr claim to
    the id_token and you can find a value with mfa inside it, if the user has done an MFA login.
    Github returns this information as well (which has been added to the template).
  • optional rauthy_admin claim mapping:
    If you want to allow full rauthy admin access for a user depending on some value returned by the upstream provider,
    you can do a mapping just like for the mfa claim above.
  • upload a logo for upstream providers
    Rauthy does not (and never will do) an automatic logo download from a provider, because this logo will be shown on the
    login page and must be trusted. However, if Rauthy would download any arbitrary logo from a provider, this could
    lead to code injection into the login page. This is why you need to manually upload a logo after configuration.

Note:
If you are testing this feature, please provide some feedback in #166
in any case - if you have errors or not. It would be nice to know about providers that do work already and those, that
might need some adoptions. All OIDC providers should work already, because for these we can rely on standards and RFCs,
but all others might produce some edge cases and I simply cannot test all of them myself.
If we have new providers we know of, that need special values, these values would be helpful as well, because Rauthy
could provide a template in the UI for these in the future, so please let me know.

Auto Image Optimization

The whole logic how images are handled has been rewritten.
Up until v0.21.1, custom client logos have been taken as a Javascript data: url because of easier handling.
This means however, that we needed to allow data: sources in the CSP for img-src, which can be a security issue and
should be avoided if possible.

This whole handling and logic has been rewritten. The CSP hardening has been finalized by removing the data: allowance
for img-src. You can still upload SVG / JPG / PNG images under the client branding (and for the new auth providers).
In the backend, Rauthy will actually parse the image data, convert the images to the optimized webp format, scale
the original down and save 2 different versions of it. The first version will be saved internally to fit into 128x128px
for possible later use, the second one even smaller. The smaller version will be the one actually being displayed on
the login page for Clients and Auth Providers.
This optimization reduces the payload sent to clients during the login by a lot, if the image has not been manually
optimized beforehand. Client Logos will typically be in the range of ~5kB now while the Auth Providers ones will usually
be less than 1kB.

6ccc541

Custom Header Name for extracting Client IPs

With the name config variable PEER_IP_HEADER_NAME, you can specify a custom header name which will be used for
extracting the clients IP address. For instance, if you are running Rauthy behind a Cloudflare proxy, you will usually
only see the IP of the proxy itself in the X-FORWARDED-FOR header. However, cloudflare adds a custom header called
CF-Connecting-IP to the request, which then shows the IP you are looking for.
Since it is very important for rate limiting and blacklisting that Rauthy knows the clients IP, this can now be
customized.

# Can be set to extract the remote client peer IP from a custom header name
# instead of the default mechanisms. This is needed when you are running
# behind a proxy which does not set the `X-REAL-IP` or `X-FORWARDED-FOR` headers
# correctly, or for instance when you proxy your requests through a CDN like
# Cloudflare, which adds custom headers in this case.
# For instance, if your requests are proxied through cloudflare, your would
# set `CF-Connecting-IP`.
PEER_IP_HEADER_NAME="CF-Connecting-IP"

a56c05e

Additional Client Data: contacts and client_uri

For each client, you can now specify contacts and a URI, where the application is hosted. These values might be shown
to users during login in the future. For Rauthy itself, the values will be set with each restart in the internal
anti lockout rule. You can specify the contact via a new config variable:

# This contact information will be added to the `rauthy`client
# within the anti lockout rule with each new restart.
RAUTHY_ADMIN_EMAIL="admin@localhost.de"

6ccc541

Custom redirect_uri During User Registration

If you want to initiate a user registration from a downstream app, you might not want your users to be redirected
to their Rauthy Account page after they have initially set the password. To encounter this, you can redirect them
to the registration page and append a ?redirect_uri=https%3A%2F%2Frauthy.example.com query param. This will be
saved in the backend state and the user will be redirected to this URL instead of their account after they have set
their password.

Password E-Mail Tempalte Overwrites

You can not overwrite the template i18n translations for the NewPassword and ResetPassword E-Mail templates.
There is a whole nwe section in the config and it can be easily done with environment variables:

#####################################
############ TEMPLATES ##############
#####################################

# You can overwrite some default email templating values here.
# If you want to modify the basic templates themselves, this is
# currently only possible with a custom build from source.
# The content however can mostly be set here.
# If the below values are not set, the default will be taken.

# New Password E-Mail
#TPL_EN_PASSWORD_NEW_SUBJECT="New Password"
#TPL_EN_PASSWORD_NEW_HEADER="New password for"
#TPL_EN_PASSWORD_NEW_TEXT=""
#TPL_EN_PASSWORD_NEW_CLICK_LINK="Click the link below to get forwarded to the password form."
#TPL_EN_PASSWORD_NEW_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_PASSWORD_NEW_EXPIRES="Link expires:"
#TPL_EN_PASSWORD_NEW_BUTTON="Set Password"
#TPL_EN_PASSWORD_NEW_FOOTER=""

#TPL_DE_PASSWORD_NEW_SUBJECT="Passwort Reset angefordert"
#TPL_DE_PASSWORD_NEW_HEADER="Passwort Reset angefordert für"
#TPL_DE_PASSWORD_NEW_TEXT=""
#TPL_DE_PASSWORD_NEW_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_PASSWORD_NEW_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_PASSWORD_NEW_EXPIRES="Link gültig bis:"
#TPL_DE_PASSWORD_NEW_BUTTON="Passwort Setzen"
#TPL_DE_PASSWORD_NEW_FOOTER=""

# Password Reset E-Mail
#TPL_EN_RESET_SUBJECT="Neues Passwort"
#TPL_EN_RESET_HEADER="Neues Passwort für"
#TPL_EN_RESET_TEXT=""
#TPL_EN_RESET_CLICK_LINK="Klicken Sie auf den unten stehenden Link um ein neues Passwort zu setzen."
#TPL_EN_RESET_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_RESET_EXPIRES="Link expires:"
#TPL_EN_RESET_BUTTON="Reset Password"
#TPL_EN_RESET_FOOTER=""

#TPL_DE_RESET_SUBJECT="Passwort Reset angefordert"
#TPL_DE_RESET_HEADER="Passwort Reset angefordert für"
#TPL_DE_RESET_TEXT=""
#TPL_DE_RESET_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_RESET_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_RESET_EXPIRES="Link gültig bis:"
#TPL_DE_RESET_BUTTON="Passwort Zurücksetzen"
#TPL_DE_RESET_FOOTER=""

Bugfix

  • UI: when a client name has been removed and saved, the input could show undefined in some cases
    2600005
  • The default path to TLS certificates inside the container image has been fixed in the deploy cfg template.
    This makes it possible now to start the container for testing with TLS without explicitly specifying the path
    manually.
    3a04dc0
  • The early Passkey implementations of the Bitwarden browser extension seem to have not provided all correct values,
    which made Rauthy complain because of not RFC-compliant requests during Passkey sign in. This error cannot really be
    reproduced. However, Rauthy tries to show more error information to the user in such a case.
    b7f94ff
  • Don't use the reset password template text for "new-password emails"
    45b4160

Images

Postgres

ghcr.io/sebadob/rauthy:0.22.0

SQLite

ghcr.io/sebadob/rauthy:0.22.0-lite

Don't miss a new rauthy release

NewReleases is sending notifications on new releases.