We’re trying to determine how big of a deal it is if we pass the client’s access token to the server in the clear (no encryption). MITM attacks could hijack the access token, but we’ve locked down the permissions using IAM.
Thanks!
We’re trying to determine how big of a deal it is if we pass the client’s access token to the server in the clear (no encryption). MITM attacks could hijack the access token, but we’ve locked down the permissions using IAM.
Thanks!
Hi @njupshot,
We don’t recommend doing that. Client credentials should be used on the trusted game server only. Putting the credentials on the game client is prone to being hacked, so we strongly advise against this action.
Sorry for the confusion Damar, but nowhere did I mention credentials. This is the access token that the client got after authenticating, not the credentials. The client is passing it so that the server can use it to verify the client is who they say they are when the client is connecting to it. The question then is, is it safe to send the token in the clear?
Sorry, when you mentioned the client’s access token, I assumed it was a token generated from client credentials. If you are referring to the user token, it should be fine since the user token only has user permissions. We already using HTTPS, so it will automatically be encrypted.
However, I’m not an expert in the security field. I’ll consult our internal team to see if they have any recommendations.
Sorry, I just realized you want to pass an access token from the client to DS. What are you trying to achieve here? Why do you need to pass the client access token to DS?
The DS should log in with client credentials and perform administrative actions, while the game client should only handle user logins. If you explain the use case, I might be able to suggest a suitable solution.
Hey Damar thank you for the response. That’s right I’m looking to pass the client’s token to the DS. The use case is I want the ds to be able to identify the user/client that is connecting to it. The game session contains the AB user IDs that are expected to join, and I only want to permit those users. The ds can’t trust that the client is who they say they are, so I figured the ds could take an access token and determine who they are via postOauthVerify.
Hi @njupshot,
We have a feature called secret validation in the session service, which can be enabled through the session template. Here’s a brief guide:
SESSION_SERVER_SECRET
topic from DSHub to receive the session secret.I hope this fulfills your needs.