Account system information

[Jupeyy]

This is the very first version of the ddnet account system.

I want to quickly go through some points, so common questions are avoided.

How does the system work?

If you technically want to understand what happens, I suggest to read src/tests/full.rs which emulates a full process of setting up the account server, clients creating accounts, clients talking to the game server.

Generally there are 3 main instances:

• account server, the secret account server
• account clients, the users that want accounts (or otherwise communicate with the account server)
• account game servers, the gameplay servers, which want to link account info to finishes (or similar)

The account client requests a login via email or steam. The account server will send a code per email, or verify the steam session ticket. Afterwards the client performs the actual login, it creates a key-pair and sends the pub key to the account server. The account server will automatically either login to an existing account or create a new one and gives the user a session for that key-pair.

When the user connects to a game server (or refreshes browser or whatever) the account client will request a certificate from the account server for its session, This cert is valid for insert any time here-time (e.g. 4 hours). Which allows the client to connect to game servers using that cert. The cert contains an extension where the account id (and theoretically other info) is stored, which allows the game server to verify that the account corresponds to that user by using the account server's public key, from whos private key was used to sign the cert that the account client just sent to the game server.
In simpler words: Account client gets a cert from account server. This cert can be trusted because all instances trust the account server. The cert cannot be faked, since it's signed by the account server.

The client uses TLS client handshake for a connection to the game server and includes the cert we just talked about here.
This allows to use the same cert on all game servers, since only the client has the private key for the public key information in the cert and the TLS handshake validates that.

The game server uses the account_id from the cert extension to either create a "local" game server account for the user,
or as fallback it can also use the fingerprint of the public key info of the cert to link secret information to a finish.
From this a neat small benefit arrises. Users that don't have an account can later claim their ranks using their non-account key-pair (basically upgrade that key-pair).

An account on the game server is actually implementation detail and we don't make any assumption about that, but this repo still contains some helper functions for what can possibly be ddnet's game server's accounts:

• auto_login, which creates accounts for valid users with accounts (and allows to check if the account was newly created to claim ranks not linked to an account, but pubkey info)
• rename, which allows the user to rename its account name.

Very quick summirization of ddnet game server accounts:

• users accounts are auto created
• users have a account name (independent of IGN), which is ascii lowercase only ([a-z],[0-9] & _]). If the db or account server is down a user can still just play, no name checks required
• if acc server is down, the public key info is still saved in finishes, which could allow reclaiming ranks

Technical overview

• Request tokens for login, link crendential, unlink credential
• Request account tokens for link another crendential, logout all sessions except this, delete account
• Login
• Link an extra credential to an exsting account (steam + email)
• Unlink a credential
• Logout
• Logout all (except current session)
• Delete
• Download current public keys of the account server
• Ping pong (only to determine fastest acc server)
• Account info, some acc info for the client to show in the account detail page (e.g. creation date)

Open problems/questions

Some open things, they wouldn't prevent the current system from working, but at least everybody is aware of them now:

• Currently the implementation only works with one type of public keys
• Other than the account clients, the account server currently uses no ed25519, because I didn't get x509 certs validated with them using rust libs
• The certs downloader of the game server only triggers once per week (or if cert is about to invalidate). Which means that the account server must know 1 week in advance if a new account server is needed. To be clear, a single account server always refreshes it's keys automatically, but adding account2.ddnet.org would take 1 week, else the game servers cannot validate the certs generated by this account server. We can always generate some keys in advance and leave them unsued to tackle this issue
• The cert extension requires an OID. Currently i simply picked a random one. You can also register one to make it more official. I personally don't care. If someone feels summoned to care, go ahead.
• Default rate limits are very aggressive per IP and not resettable without restarting the acc-server. I dunno what good rate limits are.
• Some stuff requires timing (e.g. validation times for certs) or signing timestamps. Inaccurate system clocks are a problem. I saw @def- once talking about servers being 10 minutes off. The current threshold for some operations is currently +- 20 minutes. (for requests to the acc server). If user times or game servers times are off more, that is a problem.
• if we want versioning in the URLs (account1.ddnet.org/v1/login), it must be part of the https proxy, or someone needs to add it, i didn't add it
• should sessions expire? should the private session key be rotated (updated)?

Email

@TsFreddie made an awesome email template

We'd need to host the images in templates/email on ddnet.org/email

Testing

If someone wants to seriously test this, dd-pg has most impl finished. To prevent multiple ppl asking over it over again, we could make one date where everyone that wants to test can test.

But honestly it's also not that impressive, you click "Login by steam" and it logs you in xdd
The game server allows to rename, all other stuff is hidden away for the user.

FAQ

• Can you link extra credentials (steam/email) to an existing account? Yes.
• Is this the full account integration? No, this is only the technical side of accounts + the account server and some helpers for client & game server.
• Can I use ddnet accounts for my own mod/server? Yes, that is one of the goals of this design. One account for all servers.
• Can I delete my account? Yes.
• Are ingame names bound to accounts? Yes and no. For ddnet probably not. Other mods could do it if they want.
• Can i log in with steam, but use the client without steam otherwise? Yes, you can do all account related work with steam, and then switch to a non-steam client and the steam account will still work (but you cannot do any actions like logging in, adding credentials etc.)

[PathosEthosLogos]

Can I use ddnet accounts for my own mod/server? Yes, that is one of the goals of this design. One account for all servers.

I just saw this. This would be absolutely amazing. I was gauging to see if I would need to work on another account system that already exists elsewhere, maybe like Teerace if you know, but it seems that this kind of more 'official' approach would be far better.

I put a simple static frontend together like a PoC at twelo.pages.dev

There has been huge demand for it since the beginning, I'm sure this will see big success, though I imagine technicalities will probably the biggest obstacle.

@ChillerDragon future scope for integration right here :)