auth.md

#Terms and abbreviations

Term	Definition
MCPE	Minecraft PE, or any other versions of Minecraft that we support
Player	the person who owns the client; the actual human who plays the game; the actual human who legitimately owns an account
Client	the machine that owns the MCPE app, or the MCPE app itself, owned by the player
Server	the MCPE server that has an global auth plugin, or a network of these servers
Official/Vendor	(describes) the organization that is in charge of the whole project
Database	the centralized server that hosts accounts, controlled and managed by vendor, provides limited access to servers
Global	For all servers that use the same database
Local	For only a certain server, or a certain server network
Temporary/Temp	A value that is different every time a player logins
Token	A string of printable and typable characters, specifically [a-zA-Z0-9_\-]
NP	Not possible; not practical

#Principles

• We are going to create a restful-API-like, or even a direct socket-client software that directly passes data and sets the proper permissions. We are not going to allow arbitrary database access.
• We must not force players to remember/recite/copy long tokens. I think that a 63P8 combination ([A-Za-z0-9_]{0,8}) token is the very maximum appropriate length. This is arguable and can even be customized, though.
• We should avoid, if possible, forcing the player to install apps. We should also avoid, if possible, forcing the player to switch to another app. Some operating platforms allow overlaying windows (on Android, this can be done through notifications or other types of popups like WhatsApp's, for example; but just pause the MCPE activity; don't stop it http://i.stack.imgur.com/88cpr.jpg)
• We must not let the player typing a token (password) that can be used on any servers directly into one server.
• We must let the player confirm that he is connecting to the correct server, e.g. the RSA fingerprint in SSH.

#Comparison of methods

• Client ----UUID----> Server ----UUID----> Database UUIDs can be imitated. They are not checked. Everyone can use it from anywhere once they got it.
• Client ----Client secret----> Server ----Client secret----> Database Yes we can memorize that value, but it is different for every server, and in no ways, not even through installing an app in the client, can we predict the value for a specific server.
• Client ----Global password----> Server ----Global password----> Database Same as UUID; they can be imitated.
• Client ----Local password----> Server ----Local password----> Database Then why do we need a centralized database?
• Database ----Temp token----> Client ----Temp token----> Server ----Temp token----> Database Troublesome because player has to check the new temp token every time

#Proposal

• Server registers to vendor
  • Server should register with a unique name that identifies the server or the server network; preferrably a domain name, or a subdomain name whose parent domain is not registered
• Player login
  • For the first time, player installs app or visits a website provided by vendor; possibly registers their username
    • May or may not allow nicknames (grouped accounts)
  • If player uses app, player makes sure the app is running in the background when logging in
  • Player joins server with their username.
    • If player uses an app, and tells the app that he is going to join that certain server, app may automatically modify player username (if possible) to automatically contain a temp token.
  • Server fetches a server-specific (temp or not) token from database based on player name, and shows it to the player
  • Player has to confirm that the token from the server is the token from the database
  • Player sends a temp token to the server, and server passes it to database to confirm that it is valid.