Documentation for `only_for_reauth` is wrong

[remram44]

Description

The documentation for password_config.enabled says:

Set to only_for_reauth to allow users with existing passwords to use them to log in and reauthenticate, whilst preventing new users from setting passwords.

In reality it seems that this settings only allows reauthentication, not log in.

The documentation should be fixed, but in addition the feature that is advertised in the documentation should also be made available, for example with a separate mode password_config.enabled = "hidden", that allows users with existing passwords to use them to log in. The use case is system accounts (e.g. admin, bots) which don't exist in SSO (for example in Nextcloud, when enabling SSO and disabling passwords, you can add ?direct=1 to the URL to use username+password anyway).

Steps to reproduce

• Set password_config.enabled = "only_for_reauth"
• Notice that Synapse doesn't advertise m.login.password as an authentication flow
• Try to log in with a username and password (you can't do this from unpatched Element), you will get M_UNKNOWN: MatrixError: [400] Password login has been disabled

Homeserver

my own

Synapse Version

1.73.0

Installation Method

Docker (matrixdotorg/synapse)

Database

PostgreSQL

Workers

Single process

Platform

Kubernetes

Configuration

password_config.enabled = "only_for_reauth"

Relevant log output

{"errcode":"M_UNKNOWN","error":"Password login has been disabled."}

### Anything else that would be useful to know?

_No response_

[clokep]

I think if you need users to be able to login you would need to enable password logins. Synapse doesn't know who is logging in ahead of time so it would be difficult to fulfill this for existing users?

[remram44]

I am not sure what you mean by "ahead of time"? When Synapse gets the username and password to check auth, it should allow login if that user has a password set, while still not allowing users to set their own password.

[clokep]

When Synapse gets the username and password to check auth, it should allow login if that user has a password set, while still not allowing users to set their own password.

Synapse provides the list of possible ways to login before the username and password is shown. The client than decides (based on this list) whether to present a password field, SSO buttons, etc.

[remram44]

That is why Nextcloud has this ?direct=1 trick to show the username+password form, even though it is disabled. This trick can be implemented in clients. I just need Synapse to accept the auth if it is sent and it is valid (like the documentation for only_for_reauth says it does).

[squahtx]

PRs the fix the docs welcome.

[remram44]

What about PRs to fix the behavior?

[TafkaMax]

Same problem using keycloak SSO OIDC.

I have a dimension user that I need to authenticate and it says the same thing.

Workaround? For now, allow login and get the auth token and then turn login back off.

[motey]

Yep, same here. Makes working with internal accounts cumbersome. Thanks 2 TafkaMax for the Workaround. +1 for the "hidden" option.

[remram44]

There is actually a hidden option, something you can type in your browser's JavaScript console to log in with a token. I used it a few months back, I don't remember what it is though.

edit: It's mxLoginWithAccessToken() https://github.com/matrix-org/matrix-react-sdk/pull/7261

[motey]

Yep, sure, with a token you can call the API. but in order to obtain a token you need a user+pw login first, wich will be blocked on server side if password_config.enabled is false or only_for_reauth

[remram44]

Yes it's a little orthogonal, but for my use-case (bot accounts) I was able to create tokens via the admin API and log in via Element using the hidden Element function.

I agree, I think we should still have a way to get to the user+password login.

[dklimpel]

A few ideas for a solution. Synapse has a very complex password logic at the moment.

A flag hidden.

• An admin should be able to set or remove passwords for each user via the admin api
• GET /login does not show opportunity for password login
• GET /login?direct=1 or similar shows login with password
• PUT /login allows login with passwords
• GET /capabilities shows opportunity for change password, if user has a password
• user with password are allow to change password