v0.25.0

Changes

Token Introspection

The introspection endpoint has been fixed in case of the encoding like mentioned in bugfixes.
Additionally, authorization has been added to this endpoint. It will now make sure that the request also includes
an AUTHORIZATION header with either a valid Bearer JwtToken or Basic ClientId:ClientSecret to prevent
token scanning.

The way of authorization on this endpoint is not really standardized, so you may run into issues with your client
application. If so, you can disable the authentication on this endpoint with

# Can be set to `true` to disable authorization on `/oidc/introspect`.
# This should usually never be done, but since the auth on that endpoint is not
# really standardized, you may run into issues with your client app. If so, 
# please open an issue about it.
# default: false
DANGER_DISABLE_INTROSPECT_AUTH=true

2e84ceb
7087a59

API Routes Normalization

In preparation for a clean v1.0.0, some older API routes have been fixed regarding their casing and naming.
The "current" or old routes and names will be available for exactly one release and will be phased out afterward
to have a smooth migration, just in case someone uses these renamed routes.

• /oidc/tokenInfo -> /oidc/introspect
• /oidc/rotateJwk -> /oidc/rotate_jwk

Since I don't like kebab-case, most API routes are written in snake_case, with 2 exceptions that follow RFC namings:

• openid-configuration
• web-identity

All the *info routes like userinfo or sessioninfo are not kebab_case on purpose, just to match other IdPs and
RFCs a bit more.

There is not a single camelCase anymore in the API routes to avoid confusion and issues in situations where you could
for instance mistake an uppercase I as a lowercase l. The current camelCase endpoints only exist for a smoother
migration and will be phased out with the next bigger release.

107f148

Config Read

The current behavior of reading in config variables was not working as intended.

Rauthy reads the rauthy.cfg as a file first and the environment variables afterward. This makes it possible to
configure it in any way you like and even mix and match.
However, the idea was that any existing variables in the environment should overwrite config variables and therefore
have the higher priority. This was exactly the other way around up until v0.24.1 and has been fixed now.

How Rauthy parses config variables now correctly:

1. read rauthy.cfg
2. read env var
3. all existing env vars will overwrite existing vars from rauthy.cfg and therefore have the higher priority

28b2457

Bugfixes

• The token introspection endpoint was only accepting requests with Json data, when it should have instead been
  with Form data.

Images

Postgres

ghcr.io/sebadob/rauthy:0.25.0

SQLite

ghcr.io/sebadob/rauthy:0.25.0-lite

v0.24.1

The last weeks were mostly for updating the documentation and including all the new features that came to Rauthy in the last months. Some small things are still missing, but it's almost there.

Apart from that, this is an important update because it fixes some security issues in external dependencies.

Security

Security issues in external crates have been fixed:

• moderate matrix-sdk-crypto
• moderate openssl
• low vodozemac

Changes

S3_DANGER_ACCEPT_INVALID_CERTS renamed

The config var S3_DANGER_ACCEPT_INVALID_CERTS has been renamed to S3_DANGER_ALLOW_INSECURE. This is not a breaking change right now, because for now Rauthy will accept both versions to not introduce a breaking change, but the deprecated value will be removed after v0.24.

S3 Compatibility

Quite a few internal dependencies have been updated to the latest versions (where it made sense).

One of them was my own cryptr. This was using the rusty-s3 crate beforehand, which is a nice one when working with S3 storages, but had 2 issues. One of them is that it is using pre-signed URLs. That is not a flaw in the first place, just a design decision to become network agnostic. The other one was that it signed the URL in a way that would make the request not compatible with Garage. I migrated cryptr to my own s3-simple which solves these issues.

This update brings compatibility with the garage s3 storage for Rauthy's S3 backup feature.

f1eab35

Bugfixes

• Fetching the favicon (and possibly other images) was forbidden because of the new CSRF middleware from some weeks
  ago.
  76cd728
• The UI and the backend had a difference in input validation for given_name and family_name which could make some buttons in the UI get stuck. This has been fixed and the validation for these 2 is the same everywhere and at least 1 single character is required now.
  19d512a

Images

Postgres

ghcr.io/sebadob/rauthy:0.24.1

SQLite

ghcr.io/sebadob/rauthy:0.24.1-lite

v0.24.0

Many thousands of lines have been refactored internally to provide better maintainability in the future.
These are not mentioned separately, since they did not introduce anything new. Apart from this, there are only small
changes, but one of them is an important breaking change.

Breaking

TRUSTED_PROXIES Config Variable

The new config variable TRUSTED_PROXIES introduces a breaking change in some cases.
If you are running Rauthy with either PROXY_MODE=true or with a set PEER_IP_HEADER_NAME value, you must add the
TRUSTED_PROXIES to your existing config before updating.

This value specifies trusted proxies in the above situation. The reason is that Rauthy extracts the client IP from
the HTTP headers, which could be spoofed if they are used without validating the source. This was not a security issue,
but gave an attacker the ability to blacklist or rate-limit IPs that do not belong to him.

When PROXY_MODE=true or set PEER_IP_HEADER_NAME, Rauthy will now only accept direct connections from IPs specified
with TRUSTED_PROXIES and block all other requests. You can provide a list of CIDRs to have full flexibility for your
deployment.

# A `\n` separated list of trusted proxy CIDRs.
# When `PROXY_MODE=true` or `PEER_IP_HEADER_NAME` is set,
# these are mandatory to be able to extract the real client
# IP properly and safely to prevent IP header spoofing.
# All requests with a different source will be blocked.
#TRUSTED_PROXIES="
#192.168.14.0/24
#10.0.0.0/8
#"

Note:
Keep in mind, that you must include IPs for direct health checks like for instance inside Kubernetes here,
if they are not being sent via a trusted proxy.

e1ae491

Features

User Registration Domain Blacklisting

If you are using an open user registration without domain restriction, you now have the possibility to blacklist
certain E-Mail provider domains. Even if your registration endpoint allows registrations, this blacklist will be
checked and deny requests with these domains.
This is mainly useful if you want to prevent malicious E-Mail providers from registering and spamming your database.

# If `OPEN_USER_REG=true`, you can blacklist certain domains
# on the open registration endpoint.
# Provide the domains as a `\n` separated list.
#USER_REG_DOMAIN_BLACKLIST="
#example.com
#evil.net
#"

824b109

Changes

Even though it was not needed so far, the OIDC userinfo endpoint now has a proper POST handler in addition to the
existing GET to comply with the RFC.
05a8793

Bugfixes

• The upstream crate curve25519-dalek had a moderate timing variability security issue
  8bb4069

Images

Postgres

ghcr.io/sebadob/rauthy:0.24.0

SQLite

ghcr.io/sebadob/rauthy:0.24.0-lite

v0.23.5

Upstream IdP Locale Fix

This patch fixes a regression from fixing the special characters encoding in upstream IdP JWT tokens. A panic was
possible when the upstream IdP did not include a locale in the id_token.
ea24e7e
481c9b3

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.5

SQLite

ghcr.io/sebadob/rauthy:0.23.5-lite

v0.23.4

This is a tiny update, but brings an important bugfix for upstream IdPs.

Bugfix

A bug has been fixed in case an upstream IdP included special characters inside Strings in the returned JWT token after
a successful user login flow.
Since JWT tokens should use UNICODE encoding in these cases, it is not possible to do zero-copy deserialization into
Rust UTF8 string slices in that case. This has been fixed in a way, that only when there are existing special
characters, Rauthy will now do the additional, necessary String allocations for the deserialization process.
This should fix current issues when logging in via an upstream IdP with special characters inside the E-Mail address for
instance.
aa97cb8

Apart from that, there were some minor UX improvements for the Admin UI providers setup page like earlier client side
checking of variables and preventing form submission when some required ones were missing.
9a227c9
c89fb7f

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.4

SQLite

ghcr.io/sebadob/rauthy:0.23.4-lite

v0.23.3

Changes

Documentation Updates

Updated sections in the documentation for:

• Choose database in Getting Started
• Started a new page for production setup
• Info on Android passkey status
• Encryption section
• Getting Started with Kubernetes

9f85c77

More strict origin checking

More strict checking and validation for allowed_origins has been implemented, when you configure clients. Before,
the regex only checked for the input to be a valid URI, which is not strict enough for validation an origin.
This should improve the UX and prevents hard to debug bugs, when someone enters an invalid origin.

At the same time, a better visual separation has been added to the Origins / URI section in the UI when configuring
clients.

55704f3
d993d42
8d4e455

Small performance optimizations

Small improvements have been made in a lot of places, which resulted in less memory allocations.
9144f2a

POST /authorize simplification

The logic on POST /authorize has been simplified internally. The code grew to an over-complicated state with new
features coming in all the time until a point where it was hard to follow. This has been simplified.
This makes the software better maintainable in the future.
af0db9d

Bugfix

• add all /fed_cm/ routes as exceptions to the new CSRF protection middleware
  360ce46
• upstream auth provider templates could get stuck in the UI when switching between them
  d2b928a
• when a problem with an upstream provider occurs on /callback, you will now see the detailed error in the UI
  8041c95

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.3

SQLite

ghcr.io/sebadob/rauthy:0.23.3-lite

v0.23.2

Changes

New CSRF protection middleware

CSRF protection was there already without any issues.
However, a new middleware has been added to the whole routing stack in addition to the existing checks. This provides
another defense in depth. The advantage of the new middleware is, that this can be enforced all the way in the future
after enough testing in parallel.
If this works fine without any issues, we might get rid of the current way of doing it and only use the new middleware,
which is easier to maintain and to work with.

To not break any existing deployments and make sure I did not forget route exceptions for the new middleware, you can
set it to warn-only mode for this minor release. This option will be removed in future releases though and should only
be a temporary solution:

# If set to true, a violation inside the CSRF protection middleware based
# on Sec-* headers will block invalid requests. Usually you always want this
# enabled. You may only set it to false during the first testing phase if you
# experience any issues with an already existing Rauthy deployment.
# In future releases, it will not be possible the disable these blocks.
# default: true
#SEC_HEADER_BLOCK=true

97fedf1

Experimental FedCM support

This is not really considered a new feature, but Rauthy now has experimental support for FedCM in its current state.
This is opt-in and disabled by default. You should not attempt to use it in production because the FedCM implementation
itself still has a few bumps and sharp edges.
The only reason the experimental support is there is to help smooth out these things and hopefully have FedCM as a
really nice addition. It does not really bring any new possibilities to the table, but it would improve the UX quite a
bit, if it hopefully turns out great.

#####################################
############## FED CM ###############
#####################################

## CAUTION: The FedCM is highly experimental at this point!
## Do not attempt to use it in production because it is subject to change
## in the future! The spec is currently a draft and under active development.

# Set to `true` to enable the experimental FedCM.
# default: false
#EXPERIMENTAL_FED_CM_ENABLE=false

# Session lifetime for FedCM in seconds - the session can not be extended
# beyond this time and a new login will be forced.
# default: 2592000
#SESSION_LIFETIME_FED_CM=2592000

# Session timeout for FedCM in seconds
# When a new token / login is requested before this timeout hits the limit,
# the user will be authenticated without prompting for the credentials again.
# This is the value which can extend the session, until it hits its maximum
# lifetime set with _FED_CM.
# default: 259200
#SESSION_TIMEOUT_FED_CM=259200

4689e54

Relaxed validation on ephemeral client_ids

The input validation for ephemeral client_ids has been relaxed. This now makes it possible to test them with OIDC
playgrounds, which typically generate pretty long testing URLs, which were being rejected for their length beforehand.
Rauthy now accepts URLs of up to 256 characters as client_ids.
62405bb

Bumped Argon2ID defaults

The default values for the Argon2ID hashing algorithm have been bumped up quite a bit. Rauthy's goal is to be as secure
as possible by default. The old values were quite a bit above the OWASP recommendation, but still way too low imho.
The values will of course still need tuning and adjustment to the target architecture / deployment, but they provide a
way better starting point and can be considered really secure even if not adjusted.

The new defaults are:

# M_COST should never be below 32768 in production
ARGON2_M_COST=131072
# T_COST should never be below 1 in production
ARGON2_T_COST=4
# P_COST should never be below 2 in production
ARGON2_P_COST=8

5145889
feee23e

Bugfixes

• Ephemeral client's now work properly with the /userinfo endpoint in strict-validation mode. Their validation is
  simply being skipped at that point, because it does not make much sense to do an enabled check at that point.
  90b0367
• A small bug appeared in the UI after you have added new custom user attributes. Instead of resetting the input
  values to empty strings after the registration, they were set to undefined.
  ab77595
• Because of a bug in the account overview UI, it was not possible to link an already existing account to an upstream
  IdP after the registration.
  22751ee

Images

Postgres

ghcr.io/sebadob/rauthy:0.23.2

SQLite

ghcr.io/sebadob/rauthy:0.23.2-lite

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