Sign In Register

How can we help you today?

Start a new topic
Answered

Some concerns about authToken and REST API vs SDK

I've been building up the user verification and authentication process for our app stack and currently we are at a sort of cross-roads on what process to use.

REST is the easiest and far cleaner than anything else.

What I expected: 
I make a rest API call with the URL that includes my credential type and key, along with my api key and server type(preview/live). That part is fine, but once i call something like AuthenticationRequest and then have an authToken returned, I should be able to attach that authToken to the header or body for any LogEventRequests...

As far as i've tested, the only value required to make any log event requests is a playerId which can be done before an authentication request, regardless. 

I wrote some cloud scripts and added the authToken in a JSON to scriptData and when i make a LogEventRequest REST call, i compare tokens in the player NoSQL object against the client.  Unfortunately i would have to do this comparison in every call to make sure it is not being spoofed. 

1)
My main question really is, how secure is a REST call if it is being made only with a playerId and some X credential and Y api key?

2)
Should we just opt to using the JS SDK where a log event request call happens after the authentication step?

The reason why this authToken is important to check is, GameSparks will be used as the main authentication in our app stack, with players accessing NodeJS(which handles our internal API). We want the user to do an authentication handshake with NodeJS after receiving the authToken, to compare with the GS authToken(in the player NoSQL object). 










Best Answer

Hi Yaser Saqib,


It is possible to enforce that the authToken is passed up with every request (after authentication) including LogEventRequest.

In the Portal, navigate to Configurator -> Credentials, and edit the credential type you are using to make REST requests (e.g. "device").

In the configuration screen that appears, you can choose a "REST Policy" - setting this to "Allowed with Auth Token" should mean that any requests that do not include the auth token as a parameter in the body of the request will be rejected (obviously this excludes authentication requests, which is how you obtain the authToken for a player in the first place).

For other credential types you can set the REST Policy to "Forbidden" which will reject all REST requests for that credential type, adding improved security to your game.


However, all of that said, there are a number of advantages to using one of the GameSparks SDKs over REST requests.

The REST API has a significant overhead in terms of performance, because each and every request must create a new socket, including initial handshake, exchange of keys for encrypted TLS communication, etc. This all takes time and CPU resource - if your client is making more than just an occasional request, your player experience will be reduced. That is why all the GameSparks SDKs use websockets to offer improved performance and reduced CPU overhead for your devices.


If possible, I would highly recommend using one of the SDKs over the REST API. The REST API is really provided for situations where you already have a backend server running your game and want to leverage some of the extra functionality that GameSparks can provide (e.g. MatchMaking, Leaderboards, etc.) In this scenario it is reasonable to assume that the API key and credential secret are well protected since they are not available to client devices in any form, only to your backend server.

When used as a client API you should definitely enable the authToken validation as outlined above for additional security. However, if GameSparks provides an SDK for your development environment I would certainly recommend you take that approach for the reasons already explained.


Kind regards,


Jon.



Answer

Hi Yaser Saqib,


It is possible to enforce that the authToken is passed up with every request (after authentication) including LogEventRequest.

In the Portal, navigate to Configurator -> Credentials, and edit the credential type you are using to make REST requests (e.g. "device").

In the configuration screen that appears, you can choose a "REST Policy" - setting this to "Allowed with Auth Token" should mean that any requests that do not include the auth token as a parameter in the body of the request will be rejected (obviously this excludes authentication requests, which is how you obtain the authToken for a player in the first place).

For other credential types you can set the REST Policy to "Forbidden" which will reject all REST requests for that credential type, adding improved security to your game.


However, all of that said, there are a number of advantages to using one of the GameSparks SDKs over REST requests.

The REST API has a significant overhead in terms of performance, because each and every request must create a new socket, including initial handshake, exchange of keys for encrypted TLS communication, etc. This all takes time and CPU resource - if your client is making more than just an occasional request, your player experience will be reduced. That is why all the GameSparks SDKs use websockets to offer improved performance and reduced CPU overhead for your devices.


If possible, I would highly recommend using one of the SDKs over the REST API. The REST API is really provided for situations where you already have a backend server running your game and want to leverage some of the extra functionality that GameSparks can provide (e.g. MatchMaking, Leaderboards, etc.) In this scenario it is reasonable to assume that the API key and credential secret are well protected since they are not available to client devices in any form, only to your backend server.

When used as a client API you should definitely enable the authToken validation as outlined above for additional security. However, if GameSparks provides an SDK for your development environment I would certainly recommend you take that approach for the reasons already explained.


Kind regards,


Jon.


Thanks for the prompt response. Good to know that the REST Policy can be updated to force auth tokens with requests.
We've gone with your recommendation and are now using the JS SDK to communicate with GameSparks and handle Auth.  


One question that really remains is a formal structure to then communicate with a third party API using the same authentication.  
If the user connects to GS as a first gate to our app, we then want to be able to connect to our NodeJS API when we make requests for app-specific feature handling. Every request the user makes to the API needs to be authenticated, I was thinking PassportJS could be a way to tie the GS auth tokens to our api? Not sure just yet. 

1)
Can the user use the same authentication to communicate with our third party nodejs api? e.g make nodejs api calls from the client. 

2) 
If we dont use REST to communicate with client to services, is it a good idea to use REST for communication between our third party api and GS?(For authentication purposes)..


Login to post a comment