What is the recommended way of handling player authentication using Cognito?

Question

Hello, so recently I came across this very useful [graphic](https://docs.aws.amazon.com/gamelift/latest/developerguide/gamelift-architecture.html) outlining the recommended architecture for games using GameLift. From reading various answers on this forum as well as reading some blogs, these are the following points I have concluded (please correct me if I am wrong).

1. Clients first authenticate themselves by passing their user-inputted credentials (username and password) to Cognito, and a token is generated by Cognito for the client to use in addition to other user information in future requests to a client-backend service that will handle all GameLift service requests.

2. This client-backend service could be simple AWS Lambda functions that use the AWS GameLiftClient functions and models since it is not recommended to use the GameLiftClient class directly in your game client. Therefore, the client will go through Lambda directly instead.

3. These Lambda functions will do all the dirty work in terms of using matchmaking potentially to find a game session, creating one if need be, and allocating a player session for the client. However, Lambda should just simply return the connection information for the client to join the game.

My question is, are user credentials stored in Cognito, or are they stored in a database such as DynamoDB that is connected to Cognito. Basically, how does Cognito verify a user from a set of credentials? And to further expand on this, for OAuth 2.0, how does Cognito verify users when they input a set of credentials from external providers such as Facebook, Google, etc.?

Accepted Answer

Cognito can work in two main ways (apologies if this is an over simplification) of modelling users:

You can create Users in Cognito (see UserPools) which maintain whatever data you want to model ie username, password etc and you would create your sign-in/sign up workflows here. Here all the user information is modeled and held by Congito.

Or

You have an known user population ie Facebook, Google etc that supports OAuth style workflows. You basically get an identity token that Cognito can use to validate the user but no user data is held by Cognito.

See https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-getting-started.html

Regardless, of which user 'pool' model you have you then provide an integration with an Identity Pool (or just Cognito) where users exchange their user identity for an AWS identity; short lived credentials that are attached to some role with a policy to take some actions in an AWS account.

Typically this will look like: 
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-scenarios.html#scenario-identity-pool

Cognito offers a lot of different workflows, but I would first ask yourself, do you want to model users in Cognito or do you want to use an existing set of identities (ie Twitch, Facebook etc) and does that identity provider plug into Cognito identity exchange?

For Cognito and OAuth2.0 please see: https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-user-pool-oauth-2-0-grants/

Hope that makes some sense.

For Cognito specific questions you may want to try the main AWS forums: https://forums.aws.amazon.com

Answer

@REDACTEDUSER
We are using system pretty much same as you have described, except that we are generating JSON token, and every call throught API Gateway is authorized, and if token expires, new token is generated and returned in same callback back to the user, so it can be stored locally.

And for point 3. client is requesting throught API that he want's to play, you can pass anything that you need to have for matchmaking (rank, game mode, selected character), than in callback you will include matchmaking ticket ID, and later you can every 10second check ticket status (also from client side), so player can have information about game session, and when ticket status is COMPLETED you will have connection informations on client (ip address and port) and you can open level from unreal with that informations.

-Tahir S.

Answer

Just another follow up, I have later found that the recommended approach is to use API Gateway to host these lambda functions. Therefore, game clients should make HTTP requests to these APIs hosted on gateway, which will handle the matchmaking stuff and return connection details. Of course, the request will require AWS tokens returned from Cognito after successful identification through either an external provider or user-defined pools. I just want to make sure that this somewhat aligns with the recommended practices for integrating with GameLift.

My next question would also be where should one store the access token and refresh token returned from Cognito? Would the game's local storage be safe? I am not sure where else to put these tokens so that the clients can easily access them to call API Gateway APIs. However, I am not sure how sensitive these credentials are as well as how safe local game storage is.

Answer

Hey Pip, thanks for the response.

Could you also confirm the 3 points that I listed out for the recommended flow for getting players into games? I just want to make sure that game clients are supposed to call cognito functions directly from the aws sdk rather than call an aws lambda function that calls cognito functions. I read that the reasoning behind this is that cognito has some kind of secure password transfer protocol so that the credentials never actually get sent to the server, is this somewhat true?

What is the recommended way of handling player authentication using Cognito?

Relevant content