OpenID Connect Single Sign-On Identity & Access Management
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.
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:
/oidc/session endpoint to create a session in Init state, which will return the cookie and the
correct CSRF token in a json bodyAccept: application/json header.html appended
d728317
ghcr.io/sebadob/rauthy:0.23.1
ghcr.io/sebadob/rauthy:0.23.1-lite
This release does the first preparations to prepare a future v1.0.0 release.
Quite a few values have been cleaned up or improved.
rauthy-client compatibilityIf 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.
UNSAFE_NO_RESET_BINDING in favor of PASSWORD_RESET_COOKIE_BINDINGThe 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
OFFLINE_TOKEN_LIFETIME config varOFFLINE_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
GET /clients/{id}/secretIf 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
Refresh Token switch in Admin UIThe 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
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
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.
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
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.
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.
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` from `/` as
# an example. Afterwards, just `base64 api_key_example.json | tr -d '\n'`
#BOOTSTRAP_API_KEY="ewogICJuYW1lIjogImJvb3RzdHJhcCIsCiAgImV4cCI6IDE3MzU1OTk2MDAsCiAgImFjY2VzcyI6IFsKICAgIHsKICAgICAgImdyb3VwIjogIkNsaWVudHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6IFsKICAgICAgICAicmVhZCIsCiAgICAgICAgImNyZWF0ZSIsCiAgICAgICAgInVwZGF0ZSIsCiAgICAgICAgImRlbGV0ZSIKICAgICAgXQogICAgfSwKICAgIHsKICAgICAgImdyb3VwIjogIlJvbGVzIiwKICAgICAgImFjY2Vzc19yaWdodHMiOiBbCiAgICAgICAgInJlYWQiLAogICAgICAgICJjcmVhdGUiLAogICAgICAgICJ1cGRhdGUiLAogICAgICAgICJkZWxldGUiCiAgICAgIF0KICAgIH0sCiAgICB7CiAgICAgICJncm91cCI6ICJHcm91cHMiLAogICAgICAiYWNjZXNzX3JpZ2h0cyI6IFsKICAgICAgICAicmVhZCIsCiAgICAgICAgImNyZWF0ZSIsCiAgICAgICAgInVwZGF0ZSIsCiAgICAgICAgImRlbGV0ZSIKICAgICAgXQogICAgfQogIF0KfQ=="
# The secret for the above defined bootstrap API Key.
# This must be at least 64 alphanumeric characters long.
# You will be able to use that key afterwards with setting
# the `Authorization` header:
#
# `Authorization: API-Key <your_key_name_from_above>$<this_secret>`
#BOOTSTRAP_API_KEY_SECRET=
USERINFO_STRICTYou can now set a new config variable called USERINFO_STRICT. If set so true, Rauthy will do additional
validations on the /userinfo endpoint and actually revoke (even otherwise still valid) access tokens,
when any user / client / device it has been issued for has been deleted, expired or disabled. The non-strict
mode will simply make sure the token is valid and that the user still exists. The additional validations
will consume more resources because they need 1-2 additional database lookups but will provide more strict
validation and possible earlier token revocation. If you don't need it that strict, and you are resource
constrained, set it to false.
198e7f9
at_hash in id_tokenThe Rauthy id_token now contains the access token hash at_hash claim. This is needed for additional
downstream validation, if a client provides both tokens and they are not coming from Rauthy directly.
With the additional validation of the at_hash claim, clients can be 100% sure, that a given id_token
belongs to a specific access_token and has not been swapped out.
d506865
The allowed names for roles, groups and scopes have been adjusted. Rauthy allows names of up to 64 characters
now and containing : or *. This will make it possible to define custom scopes with names like
urn:matrix:client:api:guest or urn:matrix:client:api:*.
Depending on your final deployment, you may want to change the way Rauthy's set's its cookies, for instance if you want to create your own UI endpoints but still want to be able to communicate with the API.
The default cookie setting has been changed in a way that all cookies will have the __Host- prefix now, which provides
the highest level of security. There might be cases where you don't want this and rather have the path restriction to
/auth from before, for instance when you host an additional app on the same origin behind a reverse proxy, that should
not be able to read Rauthy's cookies.
And finally, for all Safari users, since Safari does not consider localhost to be secure when testing, you can even
set insecure cookies for testing purposes.
# You can set different security levels for Rauthy's cookies.
# The safest option would be 'host', but may not be desirable when
# you host an application on the same origin behind a reverse proxy.
# In this case you might want to restrict to 'secure', which will then
# take the COOKIE_PATH from below into account.
# The last option is 'danger-insecure' which really should never be used
# unless you are just testing on localhost and you are using Safari.
#COOKIE_MODE=host
# If set to 'true', Rauthy will bind the cookie to the `/auth` path.
# You may want to change this only for very specific reasons and if
# you are in such a situation, where you need this, you will know it.
# Otherwise don't change this value.
# default: true
#COOKIE_SET_PATH=true
Rauthy can now auto-blacklist IP's that do suspicious requests, like for instance:
... and so on.
Rauthy has a "catch all" API route handler on / which looks for these by default.
By default, IPs from such requests will be blacklisted for 24 hours, but you can of course configure this.
# The "catch all" route handler on `/` will compare the request path
# against a hardcoded list of common scan targets from bots and attackers.
# If the path matches any of these targets, the IP will be blacklisted
# preemptively for the set time in minutes.
# You can disable it with setting it to `0`.
# default: 1440
SUSPICIOUS_REQUESTS_BLACKLIST=1440
# This will emit a log with level of warning if a request to `/` has
# been made that has not been caught by any of the usual routes and
# and handlers. Apart from a request to just `/` which will end in
# a redirect to `/auth/v1`, all additional path's will be logged.
# This can help to improve the internal suspicious blocklist in the
# future.
# default: false
SUSPICIOUS_REQUESTS_LOG=flase
/auth/v1/whoamiThe whoami endpoint has been changed. It does not return all headers anymore, because this could possibly leak sensitive
headers in some environments, especially with the new auth headers feature in some situations.
Instead, it only returns the peer IP that Rauthy extracted for this request. This can be very helpful if you need to
configure the extraction, for instance when you are behind a reverse proxy or CDN.
758b31c
Users in the Admin UI can now be sorted by their created_at or last_login timestamp.
Users that never have logged in will always be at the end of the list, since this value might be undefined.
4c41d64
INT4 to Rust i64 as been fixed. This came with the advantage of hacing
a few more compile-time checked queries for the users table.
1740177
/users/register endpoint in the OpenAPI documentation has been fixed, which
was referencing the wrong request body
463e424
/authorize for logins had a bit too strict validation for the user password, which had a chance that
a new password a user just set, would be rejected because of some invalid special chars not being allowed
9bb0a72
x-xss-protection header has been removed
5008438
ghcr.io/sebadob/rauthy:0.23.0
ghcr.io/sebadob/rauthy:0.23.0-lite
This version fixes a potential DoS in rustls which has been found yesterday.
f4d65a6
/forward_auth + Trusted Authn/Authz HeadersIn 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
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
ghcr.io/sebadob/rauthy:0.22.1
ghcr.io/sebadob/rauthy:0.22.1-lite
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.
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:
amr claim to
the id_token and you can find a value with mfa inside it, if the user has done an MFA login.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.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.
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.
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"
contacts and client_uriFor 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]"
redirect_uri During User RegistrationIf 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.
You can not overwrite the template i18n translations for the NewPassword and ResetPassword E-Mail templates.
There is a whole nwe section in the config and it can be easily done with environment variables:
#####################################
############ TEMPLATES ##############
#####################################
# You can overwrite some default email templating values here.
# If you want to modify the basic templates themselves, this is
# currently only possible with a custom build from source.
# The content however can mostly be set here.
# If the below values are not set, the default will be taken.
# New Password E-Mail
#TPL_EN_PASSWORD_NEW_SUBJECT="New Password"
#TPL_EN_PASSWORD_NEW_HEADER="New password for"
#TPL_EN_PASSWORD_NEW_TEXT=""
#TPL_EN_PASSWORD_NEW_CLICK_LINK="Click the link below to get forwarded to the password form."
#TPL_EN_PASSWORD_NEW_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_PASSWORD_NEW_EXPIRES="Link expires:"
#TPL_EN_PASSWORD_NEW_BUTTON="Set Password"
#TPL_EN_PASSWORD_NEW_FOOTER=""
#TPL_DE_PASSWORD_NEW_SUBJECT="Passwort Reset angefordert"
#TPL_DE_PASSWORD_NEW_HEADER="Passwort Reset angefordert für"
#TPL_DE_PASSWORD_NEW_TEXT=""
#TPL_DE_PASSWORD_NEW_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_PASSWORD_NEW_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_PASSWORD_NEW_EXPIRES="Link gültig bis:"
#TPL_DE_PASSWORD_NEW_BUTTON="Passwort Setzen"
#TPL_DE_PASSWORD_NEW_FOOTER=""
# Password Reset E-Mail
#TPL_EN_RESET_SUBJECT="Neues Passwort"
#TPL_EN_RESET_HEADER="Neues Passwort für"
#TPL_EN_RESET_TEXT=""
#TPL_EN_RESET_CLICK_LINK="Klicken Sie auf den unten stehenden Link um ein neues Passwort zu setzen."
#TPL_EN_RESET_VALIDITY="This link is only valid for a short period of time for security reasons."
#TPL_EN_RESET_EXPIRES="Link expires:"
#TPL_EN_RESET_BUTTON="Reset Password"
#TPL_EN_RESET_FOOTER=""
#TPL_DE_RESET_SUBJECT="Passwort Reset angefordert"
#TPL_DE_RESET_HEADER="Passwort Reset angefordert für"
#TPL_DE_RESET_TEXT=""
#TPL_DE_RESET_CLICK_LINK="Klicken Sie auf den unten stehenden Link für den Passwort Reset."
#TPL_DE_RESET_VALIDITY="Dieser Link ist aus Sicherheitsgründen nur für kurze Zeit gültig."
#TPL_DE_RESET_EXPIRES="Link gültig bis:"
#TPL_DE_RESET_BUTTON="Passwort Zurücksetzen"
#TPL_DE_RESET_FOOTER=""
undefined in some cases
2600005
ghcr.io/sebadob/rauthy:0.22.0
ghcr.io/sebadob/rauthy:0.22.0-lite
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.
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.
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:
DYN_CLIENT_RATE_LIMIT_SEC) from the same public IP.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
login_hintThis 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.
/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
max_age during GET /authorize and add auth_time to the ID token
9ca6970
prompt=none and prompt=login during GET /authorize
9964fa4
login_hint during GET /authorize
963644c
sub claim (see breaking changes above)
29dbe26
ghcr.io/sebadob/rauthy:0.21.0
ghcr.io/sebadob/rauthy:0.21.0-lite
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.
ghcr.io/sebadob/rauthy:0.20.1
ghcr.io/sebadob/rauthy:0.20.1-lite
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.
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:
cryptr CLI1. 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.
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!
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.
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.
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.
spowThe 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.
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:
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
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
/events API endpoint which serves archived events
d5d4b01
noindex, nofollow globally via headers and meta tag -> Rauthy as an Auth provider should never be indexed
38a2a52
address and phone default OIDC scopes and additional values for profile
3d497a2
end_session_endpoint in the OIDC metadata
3caabc9
ItemTiles UI componend used for roles, groups, and so on, wrap nicely on smaller screens
6f83e4a
UserPasswordReset and UserEmailChange events in the UI
7dc4794
ghcr.io/sebadob/rauthy:0.20.0
ghcr.io/sebadob/rauthy:0.20.0-lite
user_attr_values table to cascade rows
on user deletion for enhanced stability during user deletions
1dc730c
ghcr.io/sebadob/rauthy:0.19.2
ghcr.io/sebadob/rauthy:0.19.2-lite
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
UNSAFE_NO_RESET_BINDING like mentioned above
1f4a146
ML_LT_PWD_FIRST - set the default value in minutes (like documented) instead
of seconds. New default is ML_LT_PWD_FIRST=4320
e9d1b56
ghcr.io/sebadob/rauthy:0.19.1
ghcr.io/sebadob/rauthy:0.19.1-lite