[Authentication] only the WebClient allows authentication against OIDC

[nmarie276]

Is your feature request related to a problem? Please describe.

Hello.

I'm discovering and benchmarking SFTPGo and, on my setup, I configured the WebClient to authenticate against OIDC. But I also need to use SFTP and FTP and, on the protocol, I realized that the authentication used the local password I randomly generated during the account creation (I also use a private key for SFTP). I expected all enabled protocols were using OIDC challenge to authenticate. Tested with:

• [x] WebClient: can authenticate against OIDC
• [ ] SFTP: cannot authenticate against OIDC Uses local password and private key
• [ ] FTP: cannot authenticate against OIDC Uses local password

Not tested with WebDAV.

The goal of using OIDC is to have the same password without regarding the ingress protocol. This allows to trace who have accessed to a ressource (Authentication, Authorization, Accounting rule).

Describe the solution you'd like

Each passworded connection should be against OIDC (by sending an OIDC challenge).

Describe alternatives you've considered

No response

What are you using SFTPGo for?

Professional user, 1 person business

Additional context

No response

[drakkan]

SFTP and FTP are typically used for machine-to-machine communication, so solving an authentication challenge that requires opening a browser isn’t always practical.

That said, in the latest version of SFTPGo Enterprise, v2.7.20251107 , we’ve added support for OpenPubkey SSH. This feature may also be included in the open-source version starting from v2.8.

[nmarie276]

Hello.

I understand your arguments: actually, the workflow you described is used, for example, by rclone when reaching a OneDrive storage:

1. It creates a challenge token.
2. it displays this associated URL and asks to the user to open it into a web browser.
3. When opening this URL, the OIDC authentication validates the challenge token.

But in fact, I opened this suggestion with RedHat subscription-manager in mind:

1. The application itself asks the username and the password (or loads them from a config file or some non-interactive arguments).
2. It crafts the OIDC token.
3. It send the challenge to the Identity Provider.

The whole workflow is managed through the command-line only application.

As explained in the initial description, the main interest is to track who joined the server, from which client type and using which protocol.

Regards.