When I first started my career in software development, my networking foundation was full of holes, mostly because I didn’t take many web development courses in university, and partially because I was particularly interested in making singleplayer PC games. I took an introductory web development course, and a database administration course, but nothing else. That’s right, I knew how to write SQL queries and design database schema that optimized query speed, but I didn’t know how TCP/IP worked or how to make an http request. So, when my first job out of school was working on a multiplayer mobile game with a centralized server as the source of truth, I had to catch up. One thing that can be confusing for beginners in the networking arena is the idea of an authentication token, what it is, and how to use it. Over the years, I came up with an analogy to help explain the idea to those who haven’t seen it before.

The King’s Court

There once was a king of a vast and sprawling kingdom. There were many nobles throughout the kingdom that regularly wanted to send the king letters about many things: updating him about recent event, asking questions about new laws, making requests, and anything else a noble might want to talk to the king about. But the king had a problem: it’s easy to impersonate someone in a letter. Sure, the nobles could sign their letters, but signatures are easy to forge too.

The king considered the problem for a long time and came up with a solution. He ordered the creation of a large number of special signet rings, each with a unique design. Then he ordered every noble in the realm to come visit his court if they wanted to write him letters. When a noble arrived at court, he issued them one of the signet rings and recorded which one they received in his ledger. He told them that if they wished for him to read their letters, they needed to seal the letter with the special signet ring, otherwise he’d burn the letters without reading them.

This was a good idea, but it had some problems. If someone managed to copy or steal a noble’s ring, then they could write letters as that noble and the king might never find out. Considering this, the king decided that any noble that wanted to send him letters needed to show up to his court in person at least once every season. When a noble arrived at his court, he would give them a new ring. He recorded the date that each signet ring was issued, and if a ring was issued more that a season ago, he would stop reading letters signed with it. In this way, he could be reasonably certain that a letter signed with one of the rings was from the person to which it had been issued.

It would still be possible to steal the rings, but the expiration dates prevented an imposter from doing too much damage. Combined with other security measures, like writing in code and using trusted messengers, the king was satisfied with the plan. It balanced security with convenience. The king smiled and returned to keeping his records in order.

The Court Explained

In the above analogy, the king is the server, the nobles are the users or client applications, the signet rings are authentication tokens, and showing up to court is providing login credentials (username and password). When a user wants to access a secured web resource, like their profile information for a game, they must first login with previously created credentials. That’s usually done with a web request to a public url. If successful, the server then responds with an auth token, often a JSON Web Token (JWT) or OAuth token. The client application saves the auth token and will then attach it to any subsequent request to a secured resource. The sever can check the supplied auth token against the ones it has issued and verify the user has permission to access the resources they are requesting, without the need to supply login credentials again.

The auth token can even be saved between sessions and bypass the need to login again. Not every service will be configured to allow this, with some tokens expiring fairly quickly, but long lasting tokens are ideal for most games. The longer a token stays active, the more likely it is to fall into the hands of unauthorized parties. For games, that’s usually not a very large risk, but banks and the like are understandably highly concerned with that possibility.

Auth Tokens and Unity

In the context of multiplayer games, authentication tokens play a critical role in protecting game data, preventing unauthorized access, and safeguarding user accounts from malicious activities. By incorporating authentication tokens, game developers can ensure that players have a secure and personalized experience while maintaining the integrity of the game’s ecosystem.

UnityWebRequest is a built-in Unity API that facilitates communication between Unity games and remote servers using various protocols such as HTTP and HTTPS. It allows developers to send and receive data over the network, making it an ideal choice for implementing authentication mechanisms.

To integrate authentication tokens with UnityWebRequests, you’ll need to follow a few essential steps:

1. User Authentication:

• Implement a user authentication system, where users can register, log in, and obtain their authentication tokens.
• This system typically involves server-side logic to verify user credentials, generate tokens, and handle requests for token retrieval.

2. Token Management:

• Once a user successfully logs in, the authentication server issues an authentication token specific to that user.
• Store this token securely on the client-side (e.g., in PlayerPrefs or a secure local storage mechanism).
• Tokens should be included in subsequent requests to the server to authenticate the user.

3. Sending Authenticated Requests:

• When making requests to the server that require authentication, include the authentication token in the UnityWebRequests headers.
• UnityWebRequests provides the SetRequestHeader method to add custom headers to the outgoing requests.
• Set the appropriate header key-value pair to include the authentication token in the request.

4. Server-Side Validation:

• On the server-side, implement logic to validate the incoming requests by verifying the authentication token.
• Verify the authenticity, expiration, and permissions associated with the token to ensure the requested action is allowed.
• Return appropriate responses based on the validation results (e.g., success, unauthorized access, expired token, etc.).

To ensure the security and effectiveness of authentication tokens and UnityWebRequests in your multiplayer game, consider the following best practices:

• Always use secure communication protocols (e.g., HTTPS) to protect the transmission of authentication tokens and sensitive data.
• Implement token expiration and renewal mechanisms to enhance security and prevent long-term token abuse.
• Use server-side validation to verify authentication tokens, as client-side validation alone can be compromised.
• Regularly update and patch your authentication systems to address any security vulnerabilities that may arise.
• Monitor and log authentication-related activities to identify potential security breaches and suspicious behavior.

Conclusion

Authentication tokens are indispensable tools for securing multiplayer games and maintaining the integrity of user accounts and game data. By combining UnityWebRequests with authentication tokens, you can establish a robust and secure networking infrastructure within your Unity game.

As an experienced game programmer venturing into the world of networking, understanding the significance of authentication tokens and their integration with UnityWebRequests will empower you to build secure and engaging multiplayer experiences for your players. Embrace the power of authentication tokens and UnityWebRequests to unlock the full potential of networking in Unity! Just remember the busy king and his court and you shouldn’t have any problem understanding what these tokens are and why you need them.