As a Roblox developer, it is currently too hard to introspect Open Cloud API credentials that do not go through the OAuth 2.0 flow.
There exists an introspect endpoint for OAuth 2.0 tokens, but there is no equivalent for Open Cloud API credentials. In the current state, automation tools need to work off blind trust that everything is configured properly, or require the maintenance of a Roblox user’s auth session to stay alive.
Currently, you must pass a cookie authenticated POST request to https://apis.roblox.com/cloud-authentication/v1/apiKeys, and or GEThttps://apis.roblox.com/cloud-authentication/v1/apiKey/<apiKey>; but this workflow is not friendly to server based deployment environments.
The OAuth 2.0 /v1/token/introspect is useful for debugging, and removes the need to navigate to the creator dashboard to verify you have the correct CIDR or scope provided; this should be extended to normal Open Cloud API keys.
As a use-case; this could act as a “health check” for the remote environment to ensure an API token is valid, and has all required scopes before starting it’s process. For example, the use-case of an open-source deployment tool where new users may improperly configure their API credential- the introspect allows the application to validate the settings for them and notify the user what needs to be added/removed.
Can you explain more about a specific scenario where you hit this issue last? (specifically where you had to introspect an API key you created from the server)
Hi there! Hate to necrobump but was just running into this issue recently. I am building a platform that uses Open Cloud API Keys given to us by our customers to allow them to perform various actions from our dashboard and API that seamlessly integrates with their game (send in-game notifications, run functions, edit DataStores, etc). We couldn’t go with OAuth2 which does offer token introspection here because of the lack of some Open Cloud APIs being available through OAuth2.
It would be incredibly helpful it I could introspect the permissions, expiry date and whitelisted CIDR ranges on an API Key to avoid causing issues for my customers later down the line. Currently, to check permissions, I am just making useless requests to the APIs that I need to use to see if they return successful status codes, likely indicating that the correct scopes and IP access were given to the key. However, this is almost definitely not the best practice and doesn’t cover a token unexpectedly expiring later down the line completely breaking several features as well as the communication system between my platform and their game.
This feels like a use case where OAuth2.0 should be used instead of API keys, as you are dealing with the resources of others, especially since the software using the API key doesn’t run on the customer’s own hardware. I do not recommend using API keys here.
Taking a step back, it’s better that you request the missing functionality to be added to OAuth2.0 in a separate feature request.
If that is the case I would recommend pivoting / not pursuing functionality related to what you want to do, since there are good reasons why we would offer a set of APIs on one authentication method but not the other, specifically to avoid situations like what you are trying to do here. It’s unlikely you’ll be well supported in the future and in the worst case we might break your use in the future if we introduce additional security checks that follow the assumptions and mental model we have explained in the documentation.
Use API keys when interacting with your own resources / using software you run yourself on your local device, and use OAuth2.0 in all other scenarios when interacting with others’ resources that they give you permission for to use. If an API surface is missing let us know in separate feature requests so we can evaluate.
It would be more helpful trying to define what is OAuth and what is an API key because there’s no good way to do it right now to my knowledge (please correct me if I’m wrong).
I contribute to rblx-open-cloud and we’re working on version 2. We do a Cloud class in Python to hold their secret key, and the type of API credentials like OAuth or API Keys.