1
\$\begingroup\$

I have an architectural problem associated with authorization.

I'm making an MMORPG multiplayer mobile game without separation onto different servers. What I mean by that is that a player from USA could have a mission with someone from China.

Currently I have an authentication microservice that issues JWT tokens. Another types of microservices are game microservices that handles all game logic. By design they would scale to meet the demand.

Every account can have multiple characters created, but only one can be online at the time.

My question is: How can I ensure that only 1 character can be online? Do I attach selected character to JWT? But the player can request another JWT with another character and the previous one would be valid as well until it expires. In this case I would need to look up database with every request, but that defies the purpose of JWT. Should I be using JWT or is there another way authorize players?

\$\endgroup\$
1
\$\begingroup\$

FWIW I've never used JWT on any MMO or online game I've worked on, nor have I seen it used for such. Because of the issues you note in your question, it doesn't sound like the right tool for the job (or at least, it isn't the right tool on its own).

Generally, you'd simply boot the older connections when a newer connection came in. The method you use to authorize the connections doesn't really matter. You should authorize them somehow but beyond that, it shouldn't be too much of an issue.

In your server logic when you detect a new, valid connection from an account you simply disconnect any existing connections from that account elsewhere. You can do this before you complete the handshaking for the new connection that puts the player into the game proper.

It's probably better to do this proactively, rather than (say) invalidating the "token" used for the earlier sessions and waiting for them to disconnect as a result of trying to send data across an unauthenticated connection. It makes for a better user experience (you can specifically say on the disconnected client that it was "disconnected because you connected elsewhere"), and it minimizes the amount of time the account is connected from two locations.

You generally do not want to take an approach where you deny subsequent connections until the first connection goes away (the inverse of the above). This annoys players who accidentally leave their client running at home, go on vacation, and then can't play from their laptop until they go home again to disconnect the old session (or wait for it to time out or hope for the power to go out or whatever).

\$\endgroup\$
  • \$\begingroup\$ Thank you for the answer. Do you have any good resources I can read about game architecture? \$\endgroup\$ – Humberd Aug 16 '18 at 22:48
  • \$\begingroup\$ @Humberd I always suggest reading the source code of eAthena on GitHub (it's a Ragnarok Online server emulator). While it's in C and is a bit old by now, it used to work very well and might have lots of valuable lessons for you. \$\endgroup\$ – Gustavo Maciel Aug 21 '18 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.