The only thing to really add is that you check login attempts and reject if they have failed x times in 5 mins or whatever. This circumvents brute force attacks where they spam possibles until successful.
This actually causes an issue where someone can lock you out of your account just by using wrong passwords, so generally a notification email is sent to the owner with a verification link so they can remove the restriction.
Note: I only implemented the minimum necessary to have a complete workflow. You may end up wanting to add parameters, add steps to the workflow, etc… depending on your use-case. (For example, maybe the server sends a challenge to the client before expecting a password.) But the example shows how the back and forth can happen.
It can do lots of things. It can indicate which forms of password it expects, a message to users about to login, etc…
Presumably if the client send the login(user) request already then you know that it’s at least that much “your client”.
But for example, for Mythruna I was originally using MD5 passwords and switched to SHA-256. During the challenge I could send information about what password forms I accepted so I could still allow MD5 if they hadn’t reset them yet (but also trigger a resend as SHA-256 so I could update their user info).
I could also have done silly things like public/private certs, etc…
I guess the real “Java security” model is to say “I want to login” and then it calls you back for actual credentials using a provider.
Incidentally, that’s why I don’t have a dummy password argument on the login() method. In 100% of my own games, I’d never have a password argument.
Yeah, when the app is 100% handling its own logins then it’s usually something like:
server: challenge(message, list of auth types, additional info like one time salt or something)
client: authenticate(hashed password)
…which could also include error information.
The “message” in the challenge can be used for user-specific prompts like “Your account will expire in 10 days” or whatever… or any “you should really read this” prompt that might be necessary “Server will be going down in 4 minutes.”, etc… that they might have ignored on the main screen.
Edit: when the app is not handling its own logins and shelling out to a separate server then it might be passing auth tokens around instead.
I think I am going to write another spring server that will connect to the vault and handle authentication. This way I can manage creating credentials and tokens, resetting passwords or lost passwords, etc and I can send them web page links and stuff like that like the big boys do.
Challenge will fit right into that type of system. The GameServer would only have a small method for connecting then as the authentication server would be doing all the work.