Breaking

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

Features

OpenID Core Compatibility

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

OpenID Connect Dynamic Client Registration

Rauthy now supports Dynamic Client registration as defined here.

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

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

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

There is a whole new section in the config:

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

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

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

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

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

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

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

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

Better UX with respecting `login_hint`

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

Changes

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

Bugfixes

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

Images

Postgres

ghcr.io/sebadob/rauthy:0.21.0

SQLite

ghcr.io/sebadob/rauthy:0.21.0-lite

sebadob/rauthy v0.21.0 on GitHub