diff --git a/docs/authentication.mdx b/docs/authentication.mdx index fd7c90c58..a04e1a4f0 100644 --- a/docs/authentication.mdx +++ b/docs/authentication.mdx @@ -1,15 +1,15 @@ # Authentication -This chapter describes various ways to authenticate to Continuwuity. +This chapter describes various ways to authenticate with Continuwuity. ## Authentication flows Continuwuity implements the following authentication flows: - **OAuth login** (also known as **next-gen auth**): clients redirect the user to Continuwuity's own login and registration page to complete the authentication process. -- **Legacy login** (also known as the **UIAA** framework): clients provide their own UI to log in to or register with the server directly. +- **Legacy login** (also known as the **User Interactive Authentication** framework): clients provide their own UI to log in to or register with the server directly. -Different sets of clients support different flows, but most clients are moving towards next-gen auth. One can set which login mode(s) are allowed via the `compatibility_mode` variable of the `[global.oauth]` config file section. +Different sets of clients support different flows, but most clients are moving towards next-gen auth. One can set which login modes are allowed via the `compatibility_mode` variable of the `[global.oauth]` config file section. :::important Configure your client well-known for OAuth logins @@ -28,7 +28,7 @@ Refer to the [delegation](./guides/delegation) documentation for more details. Continuwuity can read user authentication data from the following sources: -- **Internal database** - this is the default setup for Continuwuity. It allows for registration, email, and password reset self-service. See the [**internal authentication documentation**](./authentication/internal). +- **Internal authentication** - this is the default setup, where Continuwuity reads user authentication data from its local database. It allows for registration, email, and password reset self-service. See the [**internal authentication documentation**](./authentication/internal). - **Delegated authentication** - in this mode, the server connects to an OpenID Connect identity provider for user authentication. This method allows for integrating with single sign-on services, but enabling it will disable legacy logins. See the [**delegated authentication documentation**](./authentication/oidc). diff --git a/docs/authentication/internal.mdx b/docs/authentication/internal.mdx index 65aaa8800..e1d8bb763 100644 --- a/docs/authentication/internal.mdx +++ b/docs/authentication/internal.mdx @@ -17,19 +17,17 @@ Registration is disabled by default. To enable it, set `allow_registration = tru | 7 | Static token + email | Method 2 + `require_email_for_token_registration = true` in `[global.smtp]`. See [Email configuration](#email-configuration) | | 8 | Static token + email + reCAPTCHA | Methods 3 + 7 | -Users can register on Continuwuity's account management page, or directly within a Matrix client if legacy login is enabled. - -Admin-issued tokens are the recommended method of registration. These tokens can be scoped with an expiry duration or maximum times used, and are suited for private/invite-only homeservers. See the [`!admin token`](../reference/admin/token) commands for more details. +Admin-issued tokens are the recommended registration method. These tokens are well suited for private or invite-only servers, and they can be scoped with an expiry duration or given a usage limit. See the [`!admin token`](../reference/admin/token) commands for more details. Other registration methods are meant for **untrusted, public registration**. Care must be taken when allowing these modes of operation. ## Email configuration -Continuwuity can be configured to send emails via an SMTP relay of your choice. These are used for verifying user email addresses and sending password resets links to them. +Continuwuity can be configured to send emails via an SMTP relay of your choice. These are used for verifying user email addresses and sending password reset links to them. A user is associated with only **one** email address at a time. -All email options are in the `[global.smtp]` block of the configuration file, and are toggled on when the block is uncommented. For example: +All email options are in the `[global.smtp]` block of the [configuration file](../reference/config.mdx), and are toggled on when the block is uncommented. For example: ```toml [global.smtp]