v0.23.1

Features

Global Cookie Encryption

All Rauthy cookies (except for the locale) are now encrypted globally inside the whole app by default.
This is just another defense in depth. The AEAD algorithm makes sure, that you can't tamper with the cookie values,
even if you would try to do it manually.

4fdb3f2

Easier extraction of CSRF tokens with external Frontend

If you are in the situation where you run Rauthy behind a reverse proxy on the exact same origin with another app,
and you want to build custom user facing UI parts, you had to retrieve the original HTML for /authorize or the
password reset to extract the CSRF token from the HTML content.
Doing this in tests is fine, but very tedious and wasteful for a production deployment.

For this reason, there are now 2 new possibilities:

• POST /oidc/session endpoint to create a session in Init state, which will return the cookie and the
  correct CSRF token in a json body
• the password reset link returns a json with a CSRF token instead of an HTML document, if you request it
  with a Accept: application/json header

c37e1f5

Bugfix

• the password expiry reminder E-Mail had a wrong a link to the account page, a left over from older versions
  with .html appended
  d728317

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.1

SQLite

ghcr.io/sebadob/rauthy:0.23.1-lite

v0.23.0

This release does the first preparations to prepare a future v1.0.0 release.
Quite a few values have been cleaned up or improved.

Breaking

rauthy-client compatibility

If you are using the rauthy-client, you should upgrade to v0.4.0 before
upgrade Rauthy to v0.23.0. Any older client version will not understand the new grant type for the OAuth2
Device Authorization grant.

Removal of UNSAFE_NO_RESET_BINDING in favor of PASSWORD_RESET_COOKIE_BINDING

The config variable UNSAFE_NO_RESET_BINDING has been removed in favor of PASSWORD_RESET_COOKIE_BINDING.
The logic for this security feature has been reversed. The default behavior until now was to block subsequent
requests to the password reset form if they provided an invalid binding cookie. This created issues for people
that were using evil E-Mail providers. These would scan their users E-Mails and use links inside them.
This link usage however made it impossible for "the real user" to use the link properly, because it has been
used already by its provider.
In some cases, this hurts the UX more than it is a benefit to the security, so this feature is now an opt-in
hardening instead of opt-out evil provider error fixing.
Additionally, to improve the UX even further, the additional E-Mail input form has been removed from the password
reset page as well. The security benefits of this were rather small compared to the UX degradation.
#365
1af7b92

Removal of OFFLINE_TOKEN_LIFETIME config var

OFFLINE_TOKEN_LIFETIME has been removed from the config. This variable has been deprecated since a lof
of versions now. The offline_access scope was not even allowed via the UI for a long time now, so these offline
tokens were never issued anyway.
The "new" mechanism Rauthy uses with the switch in the Admin UI to issue / allow refresh tokens for a client
is much more clear, since the offline_access scope produces a lot of confusion for people new to OIDC.
From the name, it simply makes no sense that you need to activate offline_access to get a refresh token.
Having an option named "allow refresh tokens" is just so much better.
71db7fe

Change in GET /clients/{id}/secret

If you used the endpoint for retrieving a client secret with an API key before, you need to change the method.
The endpoint works exactly the same, but the method has been changed from a GET to a POST to request and validate
the additional CSRF token from the Admin UI.
72f077f

Removal of the Refresh Token switch in Admin UI

The Refresh Token switch for a client config in the Admin UI has been removed.
The old behavior was misleading and unintuitive, I just got rid of that switch.

If you want to use the refresh flow with a client, the only thing you need to do is to allow the refresh_token flow.
You needed to do this before anyway, but in addition enable the switch further down below. So this is not really a
breaking change, but could lead to confusion, if this switch is just gone.
2ece6ed

Features

OAuth 2.0 Device Authorization Grant

This release brings support for the OAuth 2.0 Device Authorization Grant.
On top of the default RFC spec, we have some additional features like optional rate limiting and being able to
do the flow with confidential clients as well. The rauthy-client has the
basics implemented as well for fetching tokens via the device_code flow. An automatic refresh token handler is
on the TODO list though. A small
example exists as well.
You will find new sections in the account and admin -> user view, where you can see all linked devices, can give
them a friendly name and revoke refresh tokens, if they exist.
544bebe
8d028bf
e8077ce
62d41bc
51a50ac
9352b3c

Dynamic Server Side Search + Pagination

Until now, the Admin UI used client side searching and pagination. This is fine for most endpoints, but
the users can grow quite large depending on the instance while all other endpoints will return rather small
"GET all" data.
To keep big Rauthy instances with many thousands of users fast and responsive, you can set a threshold for
the total users count at which Rauthy will dynamically switch from client side to server side pagination
and searching for the Admin UI's Users and Sessions page.

# Dynamic server side pagination threshold
# If the total users count exceeds this value, Rauthy will dynamically
# change search and pagination for users in the Admin UI from client
# side to server side to not have a degradation in performance.
# default: 1000
SSP_THRESHOLD=1000

For smaller instances, keeping it client side will make the UI a bit more responsive and snappy.
For higher user counts, you should switch to do this on the server though to keep the UI fast and not
send huge payloads each time.

b4dead3
9f87af3
e6d39d1

UX Improvement on Login

The login form now contains a "Home" icon which will appear, if a client_uri is registered for the current
client. A user may click this and be redirected to the client, if a login is not desired for whatever reason.
Additionally, if the user registration is configured to be open, a link to the user registration will be shown
at the bottom as well.
b03349c
b03349c

Unlink Account from Provider

A new button has been introduced to the account view of federated accounts.
You can now "Unlink" an account from an upstream provider, if you have set it up with at least
a password or passkey before.

8b1d9a8

Link Existing Account to Provider

This is the counterpart to the unlink feature from above.
This makes it possible to link an already existing, unlinked user account to an upstream auth provider.
The only condition is a matching email claim after successful login. Apart from that, there are quite a few things
going on behind the scenes and you must trigger this provider link from an authorized, valid session from inside your
user account view. This is necessary to prevent account takeovers if an upstream provider has been hacked in some way.

fdc683c

Bootstrap default Admin in production

You can set environment variables either via rauthy.cfg, .env or as just an env var during
initial setup in production. This makes it possible to create an admin account with the very first
database setup with a custom E-Mail + Password, instead of the default [email protected] with
a random password, which you need to pull from the logs. A single API Key may be bootstrapped as well.

#####################################
############# BOOSTRAP ##############
#####################################

# If set, the email of the default admin will be changed
# during the initialization of an empty production database.
BOOTSTRAP_ADMIN_EMAIL="[email protected]"

# If set, this plain text password will be used for the
# initial admin password instead of generating a random
# password.
#BOOTSTRAP_ADMIN_PASSWORD_PLAIN="123SuperSafe"

# If set, this will take the argon2id hashed password
# during the initialization of an empty production database.
# If both BOOTSTRAP_ADMIN_PASSWORD_PLAIN and
# BOOTSTRAP_ADMIN_PASSWORD_ARGON2ID are set, the hashed version
# will always be prioritized.
BOOTSTRAP_ADMIN_PASSWORD_ARGON2ID='$argon2id$v=19$m=32768,t=3,p=2$mK+3taI5mnA+Gx8OjjKn5Q$XsOmyvt9fr0V7Dghhv3D0aTe/FjF36BfNS5QlxOPep0'

# You can provide an API Key during the initial prod database
# bootstrap. This key must match the format and pass validation.
# You need to provide it as a base64 encoded JSON in the format:
#
# ```
# struct ApiKeyRequest {
#     /// Validation: `^[a-zA-Z0-9_-/]{2,24}$`
#     name: String,
#     /// Unix timestamp in seconds in the future (max year 2099)
#     exp: Option<i64>,
#     access: Vec<ApiKeyAccess>,
# }
#
# struct ApiKeyAccess {
#     group: AccessGroup,
#     access_rights: Vec<AccessRights>,
# }
#
# enum AccessGroup {
#     Blacklist,
#     Clients,
#     Events,
#     Generic,
#     Groups,
#     Roles,
#     Secrets,
#     Sessions,
#     Scopes,
#     UserAttributes,
#     Users,
# }
#
# #[serde(rename_all = "lowercase")]
# enum AccessRights {
#     Read,
#     Create,
#     Update,
#     Delete,
# }
# ```
#
# You can use the `api_key_example.json` f...

v0.22.1

Security

This version fixes a potential DoS in rustls which has been found yesterday.
f4d65a6

Features

Dedicated /forward_auth + Trusted Authn/Authz Headers

In addition to the /userinfo endpoint specified in the OIDC spec, Rauthy implements an additional endpoint
specifically for ForwardAuth situations. You can find it at /auth/v1/oidc/forward_auth and it can be configured
to append optional Trusted Header with User Information for downstream applications, that do not support OIDC
on their own.

The HeaderNames can be configured to match your environment.
Please keep in mind, that you should only use these, if you legacy application does not support OIDC natively,
because Auth Headers come with a lot of pitfalls, when your environment is not configured properly.

# You can enable authn/authz headers which would be added to the response
# of the `/auth/v1/forward_auth` endpoint. With  `AUTH_HEADERS_ENABLE=true`,
# the headers below will be added to authenticated requests. These could
# be used on legacy downstream applications, that don't support OIDC on
# their own.
# However, be careful when using this, since this kind of authn/authz has
# a lot of pitfalls out of the scope of Rauthy.
AUTH_HEADERS_ENABLE=true

# Configure the header names being used for the different values.
# You can change them to your needs, if you cannot easily change your
# downstream apps.
# default: x-forwarded-user
AUTH_HEADER_USER=x-forwarded-user
# default: x-forwarded-user-roles
AUTH_HEADER_ROLES=x-forwarded-user-roles
# default: x-forwarded-user-groups
AUTH_HEADER_GROUPS=x-forwarded-user-groups
# default: x-forwarded-user-email
AUTH_HEADER_EMAIL=x-forwarded-user-email
# default: x-forwarded-user-email-verified
AUTH_HEADER_EMAIL_VERIFIED=x-forwarded-user-email-verified
# default: x-forwarded-user-family-name
AUTH_HEADER_FAMILY_NAME=x-forwarded-user-family-name
# default: x-forwarded-user-given-name
AUTH_HEADER_GIVEN_NAME=x-forwarded-user-given-name
# default: x-forwarded-user-mfa
AUTH_HEADER_MFA=x-forwarded-user-mfa

7d5a44a

Bugfixes

• allow CORS requests for the GET PoW and the user sign up endpoint's to make it possible to build a custom UI without
  having a server side. At the same time, the method for requesting a PoW has been changed from GET to POST.
  This change has been done because even though only in-memory, a request would create data in the backend, which should
  never be done by a GET.
  Technically, this is a breaking change, but since it has only been available from the Rauthy UI itself because of the
  CORS header setting, I decided to only bump the patch, not the minor version.
  e4d935f

Images

Postgres

ghcr.io/sebadob/rauthy:0.22.1

SQLite

ghcr.io/sebadob/rauthy:0.22.1-lite

v0.22.0

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="[email protected]"

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=...

v0.21.1

Changes

• host .well-known additionally on root /
  3c594f4

Bugfix

• Correctly show the registration_endpoint for dynamic client registration in the openid-configuration
  if it is enabled.
  424fdd1

Images

Postgres

ghcr.io/sebadob/rauthy:0.21.1

SQLite

ghcr.io/sebadob/rauthy:0.21.1-lite

v0.21.0

Breaking

The access token's sub claim had the email as value beforehand. This was actually a bug.
The sub of access token and id token must be the exact same value. sub now correctly contains the user ID,
which is 100% stable, even if the user changes his email address.
This means, if you used the sub from the id token before to get the users email, you need to pay attention now.
The uid from the id token has been dropped, because this value is now in sub. Additionally, since many
applications need the email anyway, it makes sense to have it inside the access token. For this purpose, if email
is in the requested scope, it will be mapped to the email claim in the access token.

Features

OpenID Core Compatibility

Rauthy should now be compliant with the mandatory part of the OIDC spec.
A lot of additional things were already implemented many versions ago.
The missing thing was respecting some additional params during GET /authorize.

OpenID Connect Dynamic Client Registration

Rauthy now supports Dynamic Client registration as defined here.

Dynamic clients will always get a random ID, starting with dyn$, followed by a random alphanumeric string,
so you can distinguish easily between them in the Admin UI.
Whenever a dynamic client does a PUT on its own modification endpoint with the registration_token it
received from the registration, the client_secret and the registration_token will be rotated and the
response will contain new ones, even if no other value has been modified. This is the only "safe" way to
rotate secrets for dynamic clients in a fully automated manner. The secret expiration is not set on purpose,
because this could easily cause troubles, if not implemented properly on the client side.
If you have a
badly implemented client that does not catch the secret rotation and only if you cannot fix this on the
client side, maybe because it's not under your control, you may deactivate the auto rotation with
DYN_CLIENT_SECRET_AUTO_ROTATE=false. Keep in mind, that this reduces the security level of all dynamic
clients.

Bot and spam protection is built-in as well in the best way I could think of. This is disabled, if you set
the registration endpoint to need a DYN_CLIENT_REG_TOKEN. Even though this option exists for completeness,
it does not really make sense to me though. If you need to communicate a token beforehand, you could just
register the client directly. Dynamic clients are a tiny bit less performant than static ones, because we
need one extra database round trip on successful token creation to make the spam protection work.
However, if you do not set a DYN_CLIENT_REG_TOKEN, the registration endpoint would be just open to anyone.
To me, this is the only configuration for dynamic client registration, that makes sense, because only that
is truly dynamic. The problem then are of course bots and spammers, because they can easily fill your
database with junk clients. To counter this, Rauthy includes two mechanisms:

• hard rate limiting - After a dynamic client has been registered, another one can only be registered
  after 60 seconds (default, can be set with DYN_CLIENT_RATE_LIMIT_SEC) from the same public IP.
• auto-cleanup of unused clients - All clients, that have been registered but never used, will be deleted
  automatically 60 minutes after the registration (default, can be set with DYN_CLIENT_CLEANUP_MINUTES).

There is a whole new section in the config:

#####################################
########## DYNAMIC CLIENTS ##########
#####################################

# If set to `true`, dynamic client registration will be enabled.
# Only activate this, if you really need it and you know, what
# you are doing. The dynamic client registration without further
# restriction will allow anyone to register new clients, even
# bots and spammers, and this may create security issues, if not
# handled properly and your users just login blindly to any client
# they get redirected to.
# default: false
#ENABLE_DYN_CLIENT_REG=false

# If specified, this secret token will be expected during
# dynamic client registrations to be given as a
# `Bearer <DYN_CLIENT_REG_TOKEN>` token. Needs to be communicated
# in advance.
# default: <empty>
#DYN_CLIENT_REG_TOKEN=

# The default token lifetime in seconds for a dynamic client,
# that will be set during the registration.
# This value can be modified manually after registration via
# the Admin UI like for any other client.
# default: 1800
#DYN_CLIENT_DEFAULT_TOKEN_LIFETIME=1800

# If set to 'true', client secret and registration token will be
# automatically rotated each time a dynamic client updates itself
# via the PUT endpoint. This is the only way that secret rotation
# could be automated safely.
# However, this is not mandatory by RFC and it may lead to errors,
# if the dynamic clients are not implemented properly to check for
# and update their secrets after they have done a request.
# If you get into secret-problems with dynamic clients, you should
# update the client to check for new secrets, if this is under your
# control. If you cannot do anything about it, you might set this
# value to 'false' to disable secret rotation.
# default: true
#DYN_CLIENT_SECRET_AUTO_ROTATE=true

# This scheduler will be running in the background, if
# `ENABLE_DYN_CLIENT_REG=true`. It will auto-delete dynamic clients,
# that have been registered and not been used in the following
# `DYN_CLIENT_CLEANUP_THRES` hours.
# Since a dynamic client should be used right away, this should never
# be a problem with "real" clients, that are not bots or spammers.
#
# The interval is specified in minutes.
# default: 60
#DYN_CLIENT_CLEANUP_INTERVAL=60

# The threshold for newly registered dynamic clients cleanup, if
# not being used within this timeframe. This is a helper to keep
# the database clean, if you are not using any `DYN_CLIENT_REG_TOKEN`.
# The threshold should be specified in minutes. Any client, that has
# not been used within this time after the registration will be
# automatically deleted.
#
# Note: This scheduler will only run, if you have not set any
# `DYN_CLIENT_REG_TOKEN`.
#
# default: 60
#DYN_CLIENT_CLEANUP_MINUTES=60

# The rate-limiter timeout for dynamic client registration.
# This is the timeout in seconds which will prevent an IP from
# registering another dynamic client, if no `DYN_CLIENT_REG_TOKEN`
# is set. With a `DYN_CLIENT_REG_TOKEN`, the rate-limiter will not
# be applied.
# default: 60
#DYN_CLIENT_RATE_LIMIT_SEC=60

Better UX with respecting login_hint

This is a small UX improvement in some situations. If a downstream client needs a user to log in, and it knows
the users E-Mail address somehow, maybe because of an external initial registration, It may append the correct
value with appending the login_hint to the login redirect. If this is present, the login UI will pre-fill the
E-Mail input field with the given value, which make it one less step for the user to log in.

Changes

• The /userinfo endpoint now correctly respects the scope claim from withing the given Bearer token
  and provides more information. Depending on the scope, it will show the additional user values that were
  introduced with v0.20
  49dd553
• respect max_age during GET /authorize and add auth_time to the ID token
  9ca6970
• correctly work with prompt=none and prompt=login during GET /authorize
  9964fa4
• Make it possible to use an insecure SMTP connection
  ef46414
• Implement OpenID Connect Dynamic Client Registration
  b48552e
  12179c9
• respect login_hint during GET /authorize
  963644c

Bugfixes

• Fix the link to the latest version release notes in the UI, if an update is available
  e66e496
• Fix the access token sub claim (see breaking changes above)
  29dbe26
• Fix a short route fallback flash during Admin UI logout
  6787261

Images

Postgres

ghcr.io/sebadob/rauthy:0.21.0

SQLite

ghcr.io/sebadob/rauthy:0.21.0-lite

v0.20.1

This is a small bugfix release.
The temp migrations which exist for v0.20 only to migrate existing database secrets to cryptr were causing a crash at startup for a fresh installation.
This is the only thing that has been fixed with this version. They are now simply ignored and a warning is logged into the console at the very first startup.

Images

Postgres

ghcr.io/sebadob/rauthy:0.20.1

SQLite

ghcr.io/sebadob/rauthy:0.20.1-lite

v0.20.0

Breaking

This update is not backwards-compatible with any previous version. It will modify the database under the hood
which makes it incompatible with any previous version. If you need to downgrade for whatever reason, you will
only be able to do this by applying a database backup from an older version.
Testing has been done and everything was fine in tests. However, if you are using Rauthy in production, I recommend
taking a database backup, since any version <= v0.19 will not be working with a v0.20+ database.

IMPORTANT Upgrade Notes

If you are upgrading from any earlier version, there is a manual action you need to perform, before you can
start v0.20.0. If this has not been done, it will simply panic early and not start up. Nothing will get damaged.

The internal encryption of certain values has been changed. Rauthy now uses cryptr to handle these things,
like mentioned below as well.

However, to make working with encryption keys easier and provide higher entropy, the format has changed.
You need to convert your currently used ENC_KEYS to the new format:

Option 1: Use cryptr CLI

1. Install cryptr - https://github.com/sebadob/cryptr

If you have Rust available on your system, just execute:

cargo install cryptr --features cli --locked

Otherwise, pre-built binaries do exist:

Linux: https://github.com/sebadob/cryptr/raw/main/out/cryptr_0.2.2

Windows: https://github.com/sebadob/cryptr/raw/main/out/cryptr_0.2.2.exe

2. Execute:

cryptr keys convert legacy-string

3. Paste your current ENC_KEYS into the command line.

For instance, if you have

ENC_KEYS="bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA"

in your config, paste

bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA

If you provide your ENC_KEYS via a Kubernetes secret, you need to do a base64 decode first.
For instance, if your secret looks something like this

ENC_KEYS: YlZDeVRzR2FnZ1Z5NXlxUS9TOW43b0NlbjUzeFNKTHpjc21mZG5CRHZOcnFRNjNyNCBxNnUyNm9uUnZYVkc0NDI3LzNDRUM4UkpXQmNNa3JCTWtSWGd4NjVBbUpzTlRnaFNB

Then decode via shell or any tool your like:

echo -n YlZDeVRzR2FnZ1Z5NXlxUS9TOW43b0NlbjUzeFNKTHpjc21mZG5CRHZOcnFRNjNyNCBxNnUyNm9uUnZYVkc0NDI3LzNDRUM4UkpXQmNNa3JCTWtSWGd4NjVBbUpzTlRnaFNB | base64 -d

... and paste the decoded value into cryptr

4. cryptr will output the correct format for either usage in config or as kubernetes secret again

5. Paste the new format into your Rauthy config / secret and restart.

Option 2: Manual

Rauthy expects the ENC_KEYS now base64 encoded, and instead of separated by whitespace it expects them to
be separated by \n instead.
If you don't want to use cryptr you need to convert your current keys manually.

For instance, if you have

ENC_KEYS="bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 q6u26onRvXVG4427/3CEC8RJWBcMkrBMkRXgx65AmJsNTghSA"

in your config, you need to convert the enc key itself, the value after the /, to base64, and then separate
them with \n.

For instance, to convert bVCyTsGaggVy5yqQ/S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4, split off the enc key part
S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4 and encode it with base64:

echo -n 'S9n7oCen53xSJLzcsmfdnBDvNrqQ63r4' | base64

Then combine the result with the key id again to:

bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=

Do this for every key you have. The ENC_KEYS should then look like this in the end:

ENC_KEYS="
bVCyTsGaggVy5yqQ/UzluN29DZW41M3hTSkx6Y3NtZmRuQkR2TnJxUTYzcjQ=
q6u26onRvXVG4427/M0NFQzhSSldCY01rckJNa1JYZ3g2NUFtSnNOVGdoU0E=
"

Important:
Make sure to not add any newline characters or spaces when copying values around when doing the bas64 encoding!

Encrypted SQLite backups to S3 storage

Rauthy can now push encrypted SQLite backups to a configured S3 bucket.
The local backups to data/backups/ do still exist. If configured, Rauthy will now push backups from SQLite
to an S3 storage and encrypt them on the fly. All this happens with the help of cryptr
which is a new crate of mine. Resource usage is minimal, even if the SQLite file would be multiple GB's big.
The whole operation is done with streaming.

Auto-Restore SQLite backups

Rauthy can now automatically restore SQLite backups either from a backup inside data/backups/ locally, or
fetch an encrypted backup from an S3 bucket. You only need to set the new RESTORE_BACKUP environment variable
at startup and Rauthy will do the rest. No manually copying files around.
For instance, a local backup can be restored with setting RESTORE_BACKUP=file:rauthy-backup-1703243039 and an
S3 backup with RESTORE_BACKUP=s3:rauthy-0.20.0-1703243039.cryptr.

Test S3 config at startup

To not show unexpected behavior at runtime, Rauthy will initialize and test a configured S3 connection
at startup. If anything is not configured correctly, it will panic early. This way, when Rauthy starts
and the tests are successful, you know it will be working during the backup process at night as well, and
it will not crash and throw errors all night long, if you just had a typo somewhere.

Migration to spow

The old (very naive) Proof-of-Work (PoW) mechanism for bot and spam protection has been migrated to make use
of the spow crate, which is another new project of mine.
With this implementation, the difficulty for PoW's a client must solve can be scaled up almost infinitely,
while the time is takes to verify a PoW on the server side will always be O(1), no matter hoch high the
difficulty was. spow uses a modified version of the popular Hashcat PoW algorithm, which is also being used
in the Bitcoin blockchain.

Separate users cache

A typical Rauthy deployment will have a finite amount of clients, roles, groups, scopes, and so on.
The only thing that might scale endlessly are the users. Because of this, the users are now being cached
inside their own separate cache, which can be configured and customized to fit the deployment's needs.
You can now set the upper limit and the lifespan for cached user's. This is one of the first upcoming
optimizations, since Rauthy gets closer to the first v1.0.0 release:

E-Mails as lowercase only

Up until now, it was possible to register the same E-Mail address multiple times with using uppercase characters.
E-Mail is case-insensitive by definition though. This version does a migration of all currently existing E-Mail addresses
in the database to lowercase only characters. From that point on, it will always convert any address to lowercase only
characters to avoid confusion and conflicts.
This means, if you currently have the same address in your database with different casing, you need to resolve this
issue manually. The migration function will throw an error in the console at startup, if it finds such a conflict.

# The max cache size for users. If you can afford it memory-wise, make it possible to fit
# all active users inside the cache.
# The cache size you provide here should roughly match the amount of users you want to be able
# to cache actively. Depending on your setup (WebIDs, custom attributes, ...), this number
# will be multiplied internally  by 3 or 4 to create multiple cache entries for each user.
# default: 100
CACHE_USERS_SIZE=100

# The lifespan of the users cache in seconds. Cache eviction on updates will be handled automatically.
# default: 28800
CACHE_USERS_LIFESPAN=28800

Additional claims available in ID tokens

The scope profile now additionally adds the following claims to the ID token (if they exist for the user):

• locale
• birthdate

The new scope address adds:

• address in JSON format

  The new scope phone adds:

• phone

Changes

• new POST /events API endpoint which serves archived events
  d5d4b01
• new admin UI section to fetch and filter archived events.
  ece73bb
• backend + frontend dependencies have been updated to the latest versions everywhere
• The internal encryption handling has been changed to a new project of mine called cryptr.
  This makes the whole value encryption way easier, more stable and future-proof, because values have their own
  tiny header data with the minimal amount of information needed. It not only simplifies encryption key rotations,
  but also even encryption algorithm encryptions really easy in the future.
  d6c224e
  c3df3ce
• Push encrypted SQLite backups to S3 storage
  fa0e496
• S3 connection and config test at startup
  701c785
• Auto-Restore SQLite backups either from file or S3
  65bbfea
• Migrate to spow
  ff579f6
• Pre-Compute CSP's for all HTML content at build-time and get rid of the per-request nonce computation
  8fd2c99
• noindex, nofollow globally via heade...

v0.19.2

Changes

• Invalidate all user sessions after a password reset to have a more uniform flow and better UX
  570dea6
• Add an additional foreign key constraint on the user_attr_values table to cascade rows
  on user deletion for enhanced stability during user deletions
  1dc730c

Bugfixes

• Fix a bug when an existing user with already registered passkeys would not be able
  to use the password reset functionality correctly when opened in a fully fresh browser
  24af03c
• Fix cache evictions of existing user sessions after a user has been deleted while having
  an active session
  ed76418
• Fix some default values in the reference config docs not having the correct default documented
  a7101b2

Images

Postgres

ghcr.io/sebadob/rauthy:0.19.2

SQLite

ghcr.io/sebadob/rauthy:0.19.2-lite

v0.19.1

This is a small bugfix and compatibility release regarding password reset E-Mails.

The main reason for this release are problems with the Password Reset via E-Mail when users
are using Microsoft (the only service provider where this problems can be replicated 100% of the time)
and / or Outlook. These users were unable to use password reset links at all.
The reason is a "Feature" from Microsoft. They fully scan the user's E-Mails and even follow all links
inside it. The problem is, that the binding cookie from Rauthy will go to the Microsoft servers instead
of the user, making it unusable and basically invalidating everything before the user has any chance to
use the link properly.

The usage of this config variable is highly discouraged, and you should avoid it, if you can.
However, big enterprises are moving slowly (and often not at all). This new config variable can be used
as a last resort, to make it usable by giving up some security.

# This value may be set to 'true' to disable the binding cookie checking
# when a user uses the password reset link from an E-Mail.
#
# When using such a link, you will get a so called binding cookie. This
# happens on the very first usage of such a reset link. From that moment on,
# you will only be able to access the password reset form with this very 
# device and browser. This is just another security mechanism and prevents
# someone else who might be passively sniffing network traffic to extract 
# the (unencrypted) URI from the header and just use it, before the user 
# has a change to fill out the form. This is a mechanism to prevent against
# account takeovers during a password reset.
#
# The problem however are companies (e.g. Microsoft) who scan their customers
# E-Mails and even follow links and so on. They call it a "feature". The
# problem is, that their servers get this binding cookie and the user will be
# unable to use this link himself. The usage of this config option is highly
# discouraged, but since everything moves very slow in big enterprises and
# you cannot change your E-Mail provider quickly, you can use it do just make
# it work for the moment and deal with it later.
#
# default: false
#UNSAFE_NO_RESET_BINDING=false

Changes

• implement UNSAFE_NO_RESET_BINDING like mentioned above
  1f4a146
• prettify the expiry timestamp in some E-Mails
  1173fa0

Bugfixes

• It was possible to get an "Unauthorized Session" error during a password reset, if it has been
  initiated by an admin and / or from another browser.
  e5d1d9d
• Correctly set ML_LT_PWD_FIRST - set the default value in minutes (like documented) instead
  of seconds. New default is ML_LT_PWD_FIRST=4320
  e9d1b56

Images

Postgres

ghcr.io/sebadob/rauthy:0.19.1

SQLite

ghcr.io/sebadob/rauthy:0.19.1-lite