Releases: sebadob/rauthy
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
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.
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:
- read
rauthy.cfg
- read env var
- all existing env vars will overwrite existing vars from
rauthy.cfg
and therefore have the higher priority
Bugfixes
- The token introspection endpoint was only accepting requests with
Json
data, when it should have instead been
withForm
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.
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
andfamily_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.
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
#"
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
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.
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
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
Relaxed validation on ephemeral client_id
s
The input validation for ephemeral client_id
s 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_id
s.
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
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 anenabled
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.
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 inInit
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 aAccept: application/json
header
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.
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.
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.
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
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 fromGET
toPOST
.
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 aGET
.
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