Introduction
When building an experience on Roblox, you may eventually explore beyond the platform and begin constructing web-based interfaces for interaction. Whether you are creating a third-party moderation tool, an analytics service, a feedback system, or something else, it becomes increasingly important to ensure that your platform receives only authentic and unaltered requests.
Traditionally, developers have relied on one of two methods:
- Using a single API key to authenticate all HTTP requests.
- Employing a system like rocheck to verify if the API request originates from a Roblox experience.
However, both methods have their shortcomings. For instance, using a single API key raises security concerns if that key falls into the wrong hands. Let’s say you have a system that manages a user’s standing in your experience. A bad actor with access to the key could arbitrarily decrease any user’s points and impose a ban.
How Can We Change?
In the past, these seemed like the only viable solutions for securing your systems. However, we are not limited to these options anymore. Roblox has introduced the Open Cloud system, allowing developers to interact more closely with their Roblox experiences through the Messaging Service API.
Messaging Service has a unique feature: it delivers messages directly to your experience, bypassing the need for an endpoint. The significance of this will be explained further, but for now, the key points are:
- We have been using outdated and insecure technology.
- Vital endpoints have remained vulnerable.
- Innovation with Open Cloud allows us to establish more secure practices.
Building the Frontend
By “frontend,” I refer to the experience, which acts as the client, while your web interface serves as the server. The client will bear the bulk of the responsibility for proving its trustworthiness to the server.
Possible Issues
This stage can be the most risky, not in terms of unauthorized access but in the potential for abuse of your authentication endpoint. Bad actors could flood the Open Cloud system with Messaging Service requests, triggering rate limits or even suspending your Open Cloud privileges.
Below are some rudimentary ways to protect your endpoints. These are not recommended for production but can serve as temporary solutions:
- Query Roblox for an updated list of active servers and their job-ids to cross-reference.
- Using a single API key—while previously discouraged, it is not the worst option within this context.
- Rate-limiting IPs—this could be problematic if multiple servers share the same IP.
Building the Code
Your frontend is responsible for several tasks:
- Retrieving the JobID.
- Sending a request to the authentication endpoint.
- Handling a Messaging Service request.
Experience Server Initialization
Upon server initialization, you should first send a request to your authentication endpoint with the current job-id. This enables the server to send a Messaging Service message containing both the job-id and a unique authentication code.
Messaging Service
Upon receiving the message, ensure that the job-id matches your current frontend job-id. Store this authentication code for use in future API requests.
Server Ending
You must decide how to revoke an authentication token. My recommendations are:
- Notify an endpoint on your server when a server closes to revoke the session.
- Set an expiration time for your server-side tokens.
Building the Server
By “server,” I mean your web interface and its various endpoints. Your server is responsible for:
- Receiving authentication requests.
- Generating authentication tokens.
- Managing sessions.
Authentication Endpoint
This endpoint coordinates interactions between Open Cloud and your infrastructure. Upon receiving a request, you should first generate an authentication token. You may consider using a JSON Web Token (JWT), which can store data and has an expiration date. Ensure that active sessions are tracked with their corresponding tokens and job-ids.
Session Management
Depending on your tech stack, session management can vary. Using a JWT alone won’t allow you to revoke a token; you might want to store active tokens in a database.
Authenticating
Once the server receives its authorization token, you can create additional API endpoints, like analytics, and use the token to verify the origin of the requests.
Closing Statements
This method is arguably more secure as the Messaging Service only sends messages to YOUR experiences, eliminating the risk of man-in-the-middle attacks. However, this system may not be suitable for immediate data retrieval upon server initialization due to the time taken for the handshake process.
NOTICE
This is purely theoretical and has not been tested or reviewed by security professionals. Use at your own risk and do not deploy it in a production environment. Your feedback on improvements is welcome.
Thank you for reading. Please share your thoughts!