[WIP] Support one-time passwords (e.g. for public file shares)

[theCalcaholic]

Work in-progress

This PR is functional but still in progress. I would very much appreciate architecture and implementation specific feedback while I'm working on polishing and the missing UI portion for OTP protected share creation.

• Related: Allow temporary email passwords to be one-time use only #32353

Summary

This PR adds one-time password management to Nextcloud server and integrates them with the files_sharing app.

TODO

• (core) Implement OTP core functionality
• (core) Implement OTP integration into shares
• (files_sharing) Implement creation of OTP protected shares via OCS
• (files_sharing) Implement retrieval of public OTP protected shares via UI
• (files_sharing) Implement retrieval of public OTP protected shares via OCS
• (files_sharing) Implement UI for creating OTP protected shares (files->sidebar->sharing)
• Harden bruteforce settings for endpoints
• Better email template
• Tests
• Linting
• Regenerate openapi definitions for files_sharing
• Contribute documentation for the feature

Architecture and Rationale

General concepts

OTPs (one-time password) are short-lived, single use credentials sent to users via an (according to a given threat model) trusted channel (e.g. a specific email address).

OTP Providers define a method of sending OTPs to users.

OTP Recipients are valid address definitions within the scope of an OTP provider that can be sent OTPs.

Core/Server Changes

Generic

One-time passwords are implemented with generic interfaces so that they can be used by other parts of Nextcloud than sharing.

The core functionality for one-time passwords is implemented within the \OCP and \OC namespaces. OTPs are stored within a new database table one_time_password and have a providerID, a recipient string, an expiration date and a password. The idea here is, that the OTP configuration (i.e. provider+recipient) can be long lived, while the credentials (password+expiration date) are (re-)generated per use.
Management of OTPs is implemented in \OC\OneTimePassword\Manager (implementing the injectable interface at \OCP\OneTimePassword\IManager).

\OCP\Security\PasswordContext has been extended by an OTP case to allow the creation of password policies specifically for OTPs.

Events are used to allow apps to register OTP providers. They need to hook into the GetOneTimePasswordProviders and the SendOneTimePassword events to provider their functionality. Providers also need to implement the interface \OCP\OneTimePassword\IOneTimePasswordProvider, which defines methods that allow the Manager to select providers and provide information about them.

Sharing specific

Shares (see \OCP\Share\IShare) have been extended with an one_time_password field.

The \OC\Share20\Manager has been adjusted to prioritize OTPs when checking the authentication for a share.

The template publicshareauth.php has been adjusted to receive and display OTP related information and show a button to request an OTP if it is configured for the share.

files_sharing Changes

The ShareAPIController has been extended to allow creating and updating OTP protected shares and returning the otp configuration when fetching shares. OTPs and passwords are mutually exclusive and an error will be returned when attempting to create a share with both.

The ShareController has been extended to supply template responses for public shares with otp related information.

A new ShareOTPController has been implemented that allows users to request OTPs for a share.

OTP Providers

Two OTP providers have been implemented as (core) apps: debug and email. The former allows logging OTPs to the Nextcloud Logs and the latter allows sending OTPs via email.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI