update readme and rebuild docs

README.md

@@ -12,70 +12,106 @@ with new versions.
 
 Rauthy is an OpenID Connect (OIDC) Provider and Single Sign-On solution written in Rust.
 
-**Secure by default**  
+### Secure by default
+
 It tries to be as secure as possible by default while still providing all the options needed to be compatible with
 older systems. For instance, if you create a new OIDC client, it activates `ed25519` as the default algorithm for
 token signing and S256 PKCE flow. This will not work with old clients, which do not support it, but you can of course
 deactivate this to your liking.
 
-**MFA and Passwordless Login**
+### MFA and Passwordless Login
+
+**Option 1:**  
+Password + Security Key (without User Verification):  
+Rauthy provides FIDO 2 / Webauthn login flows. If you once logged in on a new client with your username + password,
+you
+will get an encrypted cookie which will allow you to log in without a password from that moment on. You only need to
+have a FIDO compliant Passkey being registered for your account.
+
+**Option 2:**  
+Passkey-Only Accounts:  
+Rauthy supports Passkey-Only-Accounts: you basically just provide your E-Mail address and log in with
+your FIDO 2 Passkey. Your account will not even have / need a password. This login flow is restricted though to only
+those passkeys, that can provide User Verification (UV) to always have at least 2FA security.
+
+**Note:**  
+Discoverable credentials are discouraged with Rauthy. This means you will need to enter your E-Mail for the login
+(which will be auto-filled after the first one), but Rauthy passkeys do not use any storage on your device. For instance
+when you have a Yubikey which can store 25 passkeys, it will not use a single slot there even having full support.
 
-1. Option: Password + Security Key (without User Verification):  
-   Rauthy provides FIDO 2 / Webauthn login flows. If you once logged in on a new client with your username + password,
-   you
-   will get an encrypted cookie which will allow you to log in without a password from that moment on. You only need to
-   have a FIDO compliant Passkey being registered for your account.
-2. Option: Passkey-Only Accounts:  
-   Since v0.16, Rauthy supports Passkey-Only-Accounts. You basically just provide your E-Mail address and log in with
-   your
-   FIDO 2 Passkey. Your account will not even have / need a password. This login flow is restricted though to only those
-   passkeys, that can provide User Verification (UV) to always have at least 2FA security.
+### Fast and efficient
 
-**Fast and efficient**  
 The main goal was to provide an SSO solution like Keycloak and others while using a way lower footprint
 and being more efficient with resources. For instance, Rauthy can easily run a fully blown SSO provider on just a
 Raspberry Pi. It makes extensive use of caching to be as fast as possible in cases where your database is further
-away or just a bit slower, because it is maybe running on an SBC from an SD card. Most things are even cached
-for several hours (config options will come in the future) and special care has been taken into account in case of cache
-eviction and invalidation.<br />
+away or just a bit slower, because it is maybe running on an SBC from an SD card or in the cloud with the lowest storage
+bandwidth. Most things are even cached for several hours and special care has been taken into account in case of cache
+eviction and invalidation.
+
 A Rauthy deployment with the embedded SQLite, filled caches and a small set of clients and users configured typically
-only uses **between 17 and 22 MB of memory**! This is pretty awesome when comparing it to other existing solutions
+only uses **between 20 and 25 MB of memory**! This is pretty awesome when comparing it to other existing solutions
 out there. If a password from a login is hashed, the memory consumption will of course go up way higher than this
-depending on your configured Argon2ID parameters, which you got fully under control. If you use it with an external
-Postgres, the memory consumption of Rauthy itself will even be a bit lower, since it does not need to care about SQLite.
-<br />
-For achieving this speed and efficiency, some additional design tradeoffs werde made. For instance, some things you
+depending on your configured Argon2ID parameters, which you got fully under control.
+
+For achieving the speed and efficiency, some additional design tradeoffs were made. For instance, some things you
 configure statically via config file and not dynamically via UI, while most of them are configured once and then never
 touched again.
 
-**Highly Available**  
+### Highly Available
+
 Even though it makes extensive use of caching, you can run it in HA mode. It uses its own embedded distributed HA cache
 called [redhac](https://crates.io/crates/redhac), which cares about cache eviction on remote hosts.
 You can choose between a *SQLite* for single instance deployments and a *Postgres*, if you need HA. MySQL support might
 come in the future.
 
-**Nice UI**  
-Unlike many other options, `rauthy` does have a nice Admin UI which can be used to basically do almost any operation you
-might need to administrate the whole application and its users. Some Screenshots and further introduction will follow
-in the future.
+### Admin UI + User Account Dashboard
+
+Unlike many other options, `rauthy` does have an Admin UI which can be used to basically do almost any operation you
+might need to administrate the whole application and its users. There is also an account dashboard for each individual
+user, where users will get a basic overview over their account and can self-manage som values, password, passkeys, and
+so son.  
+Some Screenshots and further introduction will follow in the future.
+
+### Client Branding
 
-**Client Branding**  
 You have a simple way to create some kind of branding or stylized look for the Login page for each client.  
 The whole color theme can be changed and each client can have its own custom logo.  
 Additionally, if you modify the branding for the default `rauthy` client, it will not only change the look for the Login
 page, but also for the Account and Admin page.
 
-**Events and Auditing**  
-Since v0.17, Rauthy implements an Event-System. Events are generated in all kinds of scenarios. They can be sent via
+### Events and Auditing
+
+Rauthy comes with an Event and Alerting-System. Events are generated in all kinds of scenarios. They can be sent via
 E-Mail, Matrix or Slack, depending on the severity and the configured level. You will see them in the Admin UI in real
 time, or you can subscribe to the events stream and externally handle them depending on your own business logic.
 
-**Brute-Force and basic DoS protection**  
+### Brute-Force and basic DoS protection
+
 Rauthy has brute force and basic DoS protection for the login endpoint. Your timeout will be artificially delayed after
 enough invalid logins. It does auto-balacklist IP's that exceeded too many invalid logins, with automatic
 expiry of the blacklisting. You can, if you like, manually blacklist certain IP's as well via the Admin UI.
 
-**Already in production**  
+### IoT Ready
+
+With the possibility to run on devices with very limited resources and having compatibility for the OAuth Device
+Authorization Grant `device_code` flow, Rauthy would be a very good choice for IoT projects. The IdP itself can easily
+run on a Raspberry Pi and all headless devices can be authenticated via the `device_code` flow. The `rauthy-client`
+has everything built-in and ready, if you want to use Rust on the IoT devices as well. It has not been checked in a
+`no_std` environment yet, but the client implementation is pretty simple.
+
+### Scales to millions of users
+
+Benchmarks for v1.0.0 have not been done yet, but after some first basic tests and generating a lot of dummy data, I
+can confirm that Rauthy has no issues handling millions of users. The first very basic tests have been done with SQLite
+and ~11 million users. All parts and functions kept being fast and responsive with the only exception that the
+user-search in the admin UI was slowed down with such a high user count. It took ~2-3 seconds at that point to get a
+result, which should be no issue at all so far (Postgres tests have not been done yet).  
+The only limiting factor at that point will be your configuration and needs for password hashing security. It really
+depends on how many resources you want to use for hashing (more resources == more secure) and how many concurrent logins
+at the exact same time you need to support.
+
+### Already in production
+
 Rauthy is already being used in production, and it works with all typical OIDC clients (so far). It was just not an
 open source project for quite some time.  
 Keycloak was a rough inspiration in certain places and if something is working with Keycloak, it does with `rauthy` too

docs/config/config.html

@@ -206,14 +206,22 @@ <h1 id="reference-config"><a class="header" href="#reference-config">Reference C
 # If you don't need the extra validations, you can set this to `false` to
 # save some resources, if your clients to a lot of `/userinfo` lookups.
 # default: true
-USERINFO_STRICT=true
+#USERINFO_STRICT=true
 
 # Can be used when 'OPEN_USER_REG=true' to restrict the domains
 # for a registration. For instance, set it to
 # 'USER_REG_DOMAIN_RESTRICTION=gmail.com' to allow only
 # registrations with '[email protected]' (default: '')
 #USER_REG_DOMAIN_RESTRICTION=some-domain.com
 
+# 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
+
 # If set to 'true', this will validate the remote peer IP address with
 # each request and compare it with the IP which was used during the initial
 # session creation / login. If the IP is different, the session will be
@@ -963,6 +971,31 @@ <h1 id="reference-config"><a class="header" href="#reference-config">Reference C
 # default: false
 #DISABLE_APP_VERSION_CHECK=false
 
+#####################################
+############## 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
+
 #####################################
 ####### LIFETIMES / TIMEOUTS ########
 #####################################

docs/getting_started/docker.html

@@ -184,7 +184,7 @@ <h2 id="testing--local-evaluation"><a class="header" href="#testing--local-evalu
     -e COOKIE_MODE=danger-insecure \
     -p 8080:8080 \
     --name rauthy \
-    ghcr.io/sebadob/rauthy:0.23.1-lite
+    ghcr.io/sebadob/rauthy:0.23.2-lite
 </code></pre>
 <p>This will start the container in interactive mode with an in-memory SQLite database. Just take a look at the log at the
 logs to see the URL and first password.</p>
@@ -194,7 +194,7 @@ <h2 id="testing--local-evaluation"><a class="header" href="#testing--local-evalu
     -e DATABASE_URL=sqlite:data/rauthy.db \
     -p 8080:8080 \
     --name rauthy \
-    ghcr.io/sebadob/rauthy:0.23.1-lite
+    ghcr.io/sebadob/rauthy:0.23.2-lite
 </code></pre>
 <div id="admonition-note" class="admonition admonish-note">
 <div class="admonition-title">
@@ -279,7 +279,7 @@ <h2 id="production-setup"><a class="header" href="#production-setup">Production
     -v $(pwd)/rauthy/data:/app/data \
     -p 8080:8080 \
     --name rauthy \
-    ghcr.io/sebadob/rauthy:0.23.1-lite
+    ghcr.io/sebadob/rauthy:0.23.2-lite
 </code></pre>
 <p><strong>6. Restrict DB files access even more</strong><br />
 After rauthy has done the first start, you could harden the access rights of the SQLite files even more.<br />

docs/getting_started/k8s.html

@@ -320,7 +320,7 @@ <h3 id="create-and-apply-the-stateful-set"><a class="header" href="#create-and-a
         fsGroup: 10001
       containers:
         - name: rauthy
-          image: ghcr.io/sebadob/rauthy:0.23.1-lite
+          image: ghcr.io/sebadob/rauthy:0.23.2-lite
           imagePullPolicy: IfNotPresent
           securityContext:
             # User ID 10001 is actually built into the container at the creation for