The problem with sending unencrypted tokens is that anyone on an open WiFi (such as Starbucks) is then vulnerable to session hijacking.
Check out the "firesheep" extension from a number of years ago, that finally shamed Facebook and such to move everything to HTTPS.
A randomly generated GUID is probably fine as a token, with the caveat that it has to be random, which then means it has less than 128 bits of entropy (because other parts of the GUID space are reserved for less-random unique identifiers.)
You might be better off with a long fully random number -- 128 bits is probably fine, 256 bits is plenty.
Another option is to use a predictable session id or game id or whatever, but issue a "ticket" that consists of (userid:gameid:issuetime:hash(userid+gameid+issuetime+secret_key))
"hash" might mean "sha256" these days -- sha1 is at this point broken-ish! The benefit of this kind of ticket is that you can detect whether the ticket has expired without a database lookup, assuming your servers are in sync on time (ntp is required.)
You can then go look up the appropriate player and game data based on the identifiers provided, rather than having to indirect through a GUID.
Something to think about.

hi hplus,

I'm struggling to find much information about creating TLS connection in Unity. I'm now doubting that games implemented in Unity (at least in general) are using TLS at all. Maybe I have the wrong keyword, but googling around for 'TLS connections with Unity3d' brings up almost nothing.

I want to make sure that my game is as secure as possible within reason. So my plan is to not do authentication on the actual Master Server or Game Servers, but instead create an HTTPS based 'AuthenticationService' for authenticating users in a completely seperate web application.

My plan is to expose an endpoint on an ASP.NET MVC app which will accept the username/password, as well as allow users to create new accounts.

Any time a user logs in, he will send in plain text his username/password to my AuthService, the AuthService will validate the user using Hashed/Salted PW (or maybe Scrypt, although need to learn more abbout that - as the Scrypt examples I saw did not expose the salt).

AuthService will then Generate a 128bit unique number and send it to the client.

Client will then drop connect and connect to the Master Server using his 128bit number. The MasterServer will call out to the AuthService to validate the 128bit number is valid. Once user is matched up to a game and connects to the GameServer, the same tokenID will be used to ensure the GameServer this is a valid connection.

Anytime a user connections to another server (chat server, game server, disconnect from MasterServer and reconnects) he will continue to send that 128bit number on the initial handshake and those servers will each call out to the AuthService to make sure the ID is valid and not expired passed reasonable timeframe (still TBD..).

Does this sound like a sane approach to you? Since I don't want to implement TLS on my game code, I think this should work OK.. The altnerative to using the AuthService in this manner is to I guess use the 'ticket' system you mentioned. I'm still not sure how that works though....

(userid:gameid:issuetime:hash(userid+gameid+issuetime+secret_key))

What is 'gameid' here? the unique ID of the game as in application title? or is a session ID that the auth service generates and stores?

What is secret key? Do you have a good keyword for this scheme for me to google and learn more about?

Or should I juse use the system I described above? Do you think there will be any issues when I add new auth providers such as Facebook?

Thank you again for your time!

If you're limited to Unity, you're limited to the security features they have built in, unless you literally impement well-known encryption protocols on top.
If you use HTTPS with the Web interface in Unity, that will use proper TLS, but the Unity low-level networking does not.
Then again, the low-level networking typically just does user agent movement, which typically is less interesting from a session hijacking point of voew.
Make your servers such that they use HTTPS for anything that affects the account (dollars, password changes, perhaps friends requests and messaging) and use the Unity networking for entities/movement, and you'll probably be fine.

thanks hplus.. Is it OK from a security standpoint to re-authenticate for every single action when calling the HTTPS service for these actions? (e.g., no caching auth). I will probably use basic auth so that user can just use his username/password.

Is it OK from a security standpoint to re-authenticate for every single action when calling the HTTPS service for these actions? (e.g., no caching auth). I will probably use basic auth so that user can just use his username/password.

As long as you trust HTTPS, that's OK-ish.
Note that passwords in flight on the server or client are more susceptible to interception by people who have access on the end points.
For example, if you log each web request payload, that log might include the password.

Also, basic-auth is kind-of dumb, because you HAVE to go through the ugly web browser name/password dialog box.
An alternative is to have a field in your payload, something like:

...
  "auth":{"username":"bobo","password":"correct horse battery staple"},
...

Then you can later add auth:{token:...} if you want to support session-based authorization.

Does basic auth imply UI? I thought basic auth just meant header based, where as your example the creds are POSTed in the body. The advantage to using headers is that you can GET and POST, where as with body based, you would need to include auth inside whatever you were POSTing, so if you did want to POST actual data, you'd need a slightly more complciated body.. No?

Does basic auth imply UI?

Well, not strictly necessarily, but usually.
What typically happens is that a web browser makes a request, that needs auth.
The server returns with 401 and WWW-Authenticate header.
The browser then shows a dialog box with the realm from WWW-Authenticate and a username/password field, and tries again.

If you make sure that every web request already has the appropriate username and password, then that UI is unlikely to be shown.
If you build a "single-page app" that prompts for this information, and then provides it in each XMLHttpRequest, and doesn't reload so it would forget about it, then that could work.

Thanks man.. I'm still going to build the UI using Unity so I will be sure to include the credentials in each header by default. The Auth Service will manage the account related tasks as well as generate unique, 1 time use 128bit tokens for the Master Server to use to 'hand off' authentication to the game/chat/matchmaking services.