commit f46e9166bc5d79fef2c8dc7888c9c84bbb9cc3ad
parent 7c143bf4d8b09b7cdfbc9efcc2a7e44a0621199c
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 16 Jun 2025 11:35:51 +0200
Update documentation slightly to address #9646
Diffstat:
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
@@ -103,11 +103,15 @@ Currently, the API supports two main authentication methods:
* ``external``: With this method, no checks are done by the merchant backend.
Instead, a reverse proxy / API gateway must do all authentication/authorization checks.
* ``token``: With this method, the client must provide a ``Authorization: Bearer $TOKEN``
- header, where ``$TOKEN`` is a secret authentication token configured for the instance which must begin with the RFC 8959 prefix.
-
-Additionally, clients can send a **login token** which they may obtain from
-the ``/private/token`` endpoint. Such a login token is valid only for a
-limited period of time and can be used by clients to avoid storing the
+ header, where ``$TOKEN`` is a secret authentication token configured for the instance which must begin with the RFC 8959 prefix followed by
+ the instances password.
+ If the instance password is lost, the administrator can set a token (including the RFC 8959 prefix!) for the default instance using the ``--auth`` command line option,
+ or by restarting the service by providing an environment variable called ``TALER_MERCHANT_TOKEN``.
+ Alternatively, the ``taler-merchant-passwd`` command-line tool may be used to set the password for any instance.
+
+In addition to the password token, clients can send a **login token** which they may obtain from
+the ``/private/token`` endpoint, exchanging it for the password token.
+Such a login token is valid only for a limited period of time and can be used by clients to avoid storing the
long-term login secrets from an authentication method.
-----------------
