Ideally you should use the help from the OS. For example if you target Apple they provide this keychain API made for that.

https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_keychain

But looking I found this apparently portable lib https://github.com/hrantzsch/keychain

Windows and Linux do not appear to provide as much security as macOS but this lib appear to do its best.

I think most applications store it in plain text, but makes sure the file is only readable by the current user. This way, we rely on the protection of the OS, instead of doing it ourselves. (I'm not a desktop app developer, so I might be completely wrong, but I think this is what e.g. Firefox does).

As far as I know, the correct way of handling authentication for a desktop applications is using OAuth and "Authentication Code with PKCE" flow. This way, you won't have to store the password at all.

But Lemmy doesn't support OAuth as of now. So, if you want users to be able to use the application without entering credentials, you will have two options:

1. Store the password under current user
2. Store the token you receive after the login (the token doesn't expire)

Lemmy may decide to expire tokens in the future (that's the correct thing to do, in my opinion).

Pretty much every OS has some solution to this called a keyring, e.g.:

• https://wiki.archlinux.org/title/GNOME/Keyring
• https://stackoverflow.com/questions/9221245/how-do-i-store-and-retrieve-credentials-from-the-windows-vault-credential-manage

These can be used to basically delegate that job to somebody else. They typically work by protecting the keyring contents with the user's system credentials.

You deskktop app could login to Lemmy via the web app and store the login cookie as it's token for future access. This security is effectively on-par with the existing web app in terms of what happens if the machine falls into bad hands.

But the same thing via an API would be preferred.

The idea that you can login to a website and get a cookie that last 3 weeks may feel absurd, but when you think about clients keeping unencrypted passwords it sort of makes it more appealing comparitively. Especially if you can lock down the cookie to the hardware to prevent theft somehow.

You can password-protect a SQLite database, although you'd have to store the password within the app which raises other issues.