Here is the code in question that blocks user administration.

Would a solution be to add a new LoginType to this list?

Make it something like

	// LoginTypeNone is used if no login method is available for this user.
	// If this is set, the user has no method of logging in.
	// API keys can still be created by an owner and used by the user.
	// These keys would use the `LoginTypeToken` type.
	LoginTypeNone LoginType = "none"

When creating a user, you can specify this login type. It would prevent the /login route from ever authenticating a user, and the user would need to find an alternative method (like having an owner generate them a key).

We should probably clarify that existing API keys are still valid. So if you switch a user's login type to this, it does not log them. But I don't think we support that functionality yet so it's ok?

@ammario thoughts?

I wonder if there's a way we could satisfy the use case without adding another knob. Maybe we could just allow users to be created without passwords when disable-password-auth is set?

The thing about no password is that then the condition for all password auth related things is:

if user.LoginType == database.LoginTypePassword && user.HashedSecret == "" {
   // No password set
}

Mainly I am thinking that if a user is created without a password, actions like "reset password" should fail.

All password interactions should fail.

LoginTypeNone is another knob, but it is also another authentication mode for a user. So I think it is valid.

Ok. Sounds good to me.

@ammario something I wonder about is should this user be able to make more api keys from one?

If we disable login, an admin can make them a token. They can use that token to make more tokens.

Oh duh, we can add a scope to the key. Nvm!!

@ammario thoughts on #8011?