[SEO Subhead]
This Guidance demonstrates how to deploy a custom, lightweight, and scalable cross-platform game identity component, along with steps on how to use the identities to authenticate against custom game backend components on AWS. This Guidance supports guest identities and various game platform identity systems. It can also be extended for any additional game platforms, such as game consoles, by using the existing integrations as templates.
In addition, this Guidance provides software development kits (SDKs) and sample code for Unreal Engine 5, Unity 2021 (and up), and Godot 4 game engines. The SDKs integrate with the identity component of this Guidance and your custom backend features.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
The AWS Lambda function generate-keys is invoked every 7 days.
Step 2
Generate-keys gets the latest public jwks.json file from Amazon Simple Storage Service (Amazon S3), generates new public keys (JSON Web Key Set (JWKS)), and private keys, and updates Amazon S3 with the new public key and the previous key.
Step 3
Generate-keys updates the private key that is used to generate JSON Web Tokens (JWT) to AWS Secrets Manager.
Step 4
The game client uses the provided software development kit (SDK) to request a new guest identity. Or, the game client can sign in with their existing guest identity by sending the guest_secret through Amazon API Gateway, which is protected by AWS WAF rules.
Step 5
The login-as-guest Lambda function validates the guest identity, or creates a new one to the UserTable in Amazon DynamoDB.
Step 6
The Lambda function requests the private key from Secrets Manager, generates a signed JWT token for the client, and sends it back.
Step 7
The game client can now call custom backend components by sending requests with the JWT token in the Authorization header using the SDK.
Step 8
The backend components validate the token by requesting the JWKS public keys from the public endpoint through Amazon CloudFront, which gets the file from Amazon S3.
Step 9
The SDK automatically refreshes the JWT access token by calling refresh-access-token Lambda function through API Gateway. The function generates a new token using the private key from Secrets Manager.
Step 10
Additionally, the game client can send access tokens from the game platform-specific identity provider to link to an existing account, or create a new account.
The Lambda functions validate the tokens and create the link to the user account in a specific DynamoDB table. Then it generates a JWT token for the client using the private key from Secrets Manager.
Step 1
The AWS Lambda function generate-keys is invoked every 7 days.
Step 2
Generate-keys gets the latest public jwks.json file from Amazon Simple Storage Service (Amazon S3), generates new public keys (JSON Web Key Set (JWKS)), and private keys, and updates Amazon S3 with the new public key and the previous key.
Step 3
Generate-keys updates the private key that is used to generate JSON Web Tokens (JWT) to AWS Secrets Manager.
Step 4
The game client uses the provided software development kit (SDK) to request a new guest identity. Or, the game client can sign in with their existing guest identity by sending the guest_secret through Amazon API Gateway, which is protected by AWS WAF rules.
Step 5
The login-as-guest Lambda function validates the guest identity, or creates a new one to the UserTable in Amazon DynamoDB.
Step 6
The Lambda function requests the private key from Secrets Manager, generates a signed JWT token for the client, and sends it back.
Step 7
The game client can now call custom backend components by sending requests with the JWT token in the Authorization header using the SDK.
Step 8
The backend components validate the token by requesting the JWKS public keys from the public endpoint through Amazon CloudFront, which gets the file from Amazon S3.
Step 9
The SDK automatically refreshes the JWT access token by calling refresh-access-token Lambda function through API Gateway. The function generates a new token using the private key from Secrets Manager.
Step 10
Additionally, the game client can send access tokens from the game platform-specific identity provider to link to an existing account, or create a new account.
The Lambda functions validate the tokens and create the link to the user account in a specific DynamoDB table. Then it generates a JWT token for the client using the private key from Secrets Manager.
Get Started
Deploy this Guidance
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
The custom identity component in this Guidance utilizes AWS X-Ray that traces user requests, and leverages Lambda Powertools to provide detailed information from within the backend logic. In addition, all components of this Guidance use Amazon CloudWatch to track logs of virtual private cloud (VPC) flows, API Gateway access, Amazon S3 access, Lambda completions, and AWS Fargate tasks. Finally, AWS CDK allows for controlled changes and consistent configuration across environments, helping you to meet your security and compliance needs.
-
SecurityRead the Security whitepaper
To support robust identity management, the custom identity component of this Guidance manages player identities and authentication. All other features of this Guidance secure access by validating JSON Web Tokens against public keys provided by the identity component. The custom identity component is protected by AWS WAF, a web application firewall that protects applications against common web exploits. Also, all data is encrypted at rest, as well as in transit.
-
ReliabilityRead the Reliability whitepaper
This Guidance mainly leverages fully managed services that are highly available by default across multiple Availability Zones (AZ) within an AWS Region. For Fargate, a multi-AZ configuration is utilized for high availability and all database tables in DynamoDB are protected with point-in-time recovery.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
This Guidance combines a number of different approaches to allow for various features to improve performance. First, the services selected for this Guidance are designed to perform at scale for game launches and other spikes in traffic by leveraging the automatically scaling components of serverless services. Next, the X-Ray data provided from the custom identity component allows developers to find congestion and calibrate the Guidance to their needs to optimize performance. Finally, the public keys that validate the JSON Web Tokens are provided through CloudFront to optimize latency for backend components.
-
Cost OptimizationRead the Cost Optimization whitepaper
This Guidance leverages serverless components when possible, allowing you to pay only for the exact resources you use. To further help with cost, consider AWS Savings Plans that can be utilized to optimize the cost for both Lambda and Fargate. Also, moving from on-demand DynamoDB tables to auto-scaling provisioned capacity allows you to use DynamoDB reserved capacity to reduce costs when the baseline traffic is known.
All services utilized in this Guidance are configured to scale based on demand, including API Gateway, Lambda, DynamoDB, Amazon S3, Fargate, Secrets Manager, and AWS WAF, ensuring that only the minimum resources are required.
-
SustainabilityRead the Sustainability whitepaper
The components of serverless services in this Guidance scale automatically, allowing the components to scale while continually matching the load with only the minimum resources needed. This reduces the environmental impact of the infrastructure by avoiding provisioning unused capacity.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.