New login mechanism that supports indieauth

[mattl]

Thinking about this. Feedback welcome.

Moving forward Libre.fm will implement a different password system for all accounts. This isn’t happening tomorrow but will be delivered as a day-one part of the new Hacienda software.

Your user account will be protected by 2FA.
We’ll support all the usual features such as supporting Yubikey type devices and passkeys and all that jazz. We will not support SMS.

We may also try to implement popular third party login systems (ie. Sign in with Facebook) but those may prove too annoying for your humble developer to implement.

Once logged in, you’ll be able generate any number of client accounts. These will replace the way you currently authenticate within a client application. Instead of using your existing username/password in a music client, you’ll use these instead. These usernames are never public facing, they’re simply designed for your computer (or computers) to talk to us.

Generating them will be easy and instant. The password will be automatically generated for you and once you navigate away from that page it will never be shown again. If you lose it, generate a new one.

Ideally you’ll use these one per app, so you’ll use a different username to authenticate your Spotify account with us from the one you use for VLC. We can’t stop you from not doing that of course, but it will be better if you don’t.

I don’t see any reason we should need to limit these but maybe we’ll let everyone have 50 such username/password combos? I suspect most people will use two, maybe three?

Anyway, let me know what you think below.

[IdotMaster1]

Sounds like a good plan!

[janerationx]

Excellent idea.

[gergelypolonkai]

I really like the idea.

Also, if you want to keep existing lingo between different services, these “client accounts” are usually called “app passwords”. Maybe itʼs a good idea to stick to that name so users may know what this is all about.

[mattl]

Support IndieAuth as per https://roadmap.libre.fm

[mattl]

• A domain name is potentially 255 characters.
• User with a very long domain name signs up via IndieAuth
• Needs an app password

Please take a look at https://bored.city/demo.html and let me know what you think. @foocorp/beta-testers would love your feedback especially.

[millette]

Actually:

The maximum length of each label is 63 characters, and a full domain name can have a maximum of 253 characters.

[virtadpt]

@mattl Use case: Mobile phone as audio player with a mobile scrobbler running in the background.

The username generated seems okay.. a bit long, and the generated string at the end would be a pain to hunt and peck. The password would be very difficult to enter.

I'm not sure there's a good way to go about this for the mobile case.

[jcorporation]

Why new username + password and not only a token as Listenbrainz implemented it?

[mattl]

@virtadpt why wouldn’t you copy and paste it once?

@millette where are you quoting that from?

@jcorporation I’m not paying much attention to ListenBrainz at this point in development of this. Are you saying they use a token for clients instead of a unique username? Do they support IndieAuth?

[jcorporation]

I do not think they support IndieAuth. IndieAuth is also new for me…

Using only an Access token for Clients is a Common implementation, not only at Listenbrainz.

[virtadpt]

@mattl That's a good point.

[mattl]

@jcorporation which clients? I’ve not seen a client ask for a token. Perhaps you can share a little more about how you’ve seen that work?

Last.fm’s own implementation of usernames is a 2-15 character name. I believe we require 4 characters minimum right now and 16 characters maximum.

[jcorporation]

Here is my implementation for a ListenBrainz scrobbler: https://github.com/jcorporation/mympd-scripts/blob/main/ListenBrainz/ListenBrainzScrobbler.lua

As you can see, I submit only an Authorization Header with a token. This is the easiest for scrobbling Clients.

Official doc: https://listenbrainz.readthedocs.io/en/latest/users/api/index.html

[mattl]

A lot of the clients I’ve seen take a user name/password.

[jcorporation]

If Authentication is as simple as the token attempt to implement for a client it is good in my perspective.

[stinerman]

I don’t see any reason we should need to limit these but maybe we’ll let everyone have 50 such username/password combos? I suspect most people will use two, maybe three?

What is the benefit of putting a limit on it? Is there a security reason? Keeping someone from being a jerk and generating millions of records?

I'm not saying I need more than 50, I'm just curious as to what a limit gets you.

[mattl]

A limit makes sense when we’re talking about hundreds of thousands of users.

[jcorporation]

From Security perspective a Limit is always a good idea, even a high one.

[mattl]

If Authentication is as simple as the token attempt to implement for a client it is good in my perspective.

I'm not sure what you're saying here. Lots of clients, including MPD support a cleartext password and username. The password is MD5 hashed right now. I would love to move away from this.

[jcorporation]

It should be easy for a client to submit the credentials in a scrobble request. The easiest is a token in the authorization header in a https request.

Hashing the password with MD5 and storing it in the backend is clearly not a good idea.

[mattl]

@jcorporation I think you're talking about new clients?

I'm talking about the vast number of existing clients we already support. They're never going to change. This mechanism will help users by separating the existing username/password combination with app passwords for clients.

[jcorporation]

Correct, I talk about new clients.

[mattl]

Okay. That’s off-topic for this issue.