API Key Management
E
Eli G
"...ability to generate namespaced api keys with certain permissions for app creation..."
Order of importance:
- Rate limit factor
- Security
- Management
As an app creator having API keys assigned at the user level w/ rate limiting can be challenging to manage for security (rotation/isolation) and stability on external apps.
Having the ability to generate namespaced api keys with certain permissions for app creation would speed up development of apps and provide better stability/maintenance/security of the apps.
Some Examples:
- Single admin uses their key for multiple apps and resets api keys and forgets all the places impacted
- Single admin does same as above yet hits rate limit.
- Using a users api key on backend for a website that has client-side form submission in a web app could cause important information to be lost due to rate limiting and accidental key rotation.
Federico Pozzato
I would like to add another use case we're facing many times as partners: our customers ask us to build API calls to fill data in Smartsuite and we do this using a "technical" user with its API key. If another customer asks for the same service, we're forced to use the same API key if we want to use the same technical user. But this is not the best solution for many reasons, the first one is that we'll have to setup again every call if we need to recreate the token. IMHO, every API tokens should belong to a user in a specific workspace.
Nate Montgomery @ SmartSuite
Merged in a post:
Add the ability to create limited API Keys per solution / app
lorenzo
It would be great if we could generate API keys per solution / app (and maybe also define the allowed methods). This enhances security when setting up API connections for third-party apps or web use. Additionally, it empowers making the API public worry-free, ensuring restricted access to sensitive records
Nate Montgomery @ SmartSuite
Merged in a post:
Option to create multiple API keys with different scopes, methods
lorenzo
We would love to see the option for generating multiple API keys with specific limits on:
- The solutions/apps they can access.
- Allowed methods (Get, Post, Update, Delete).
- Rate limits.
- Additional security features (optional).
In our case, we need to display certain information from our database on our website. Implementing this would be straightforward with an API key that has access only to the specific data/table and is restricted to Get requests. Currently, we need to set up a proxy server to store the main API key for secure communication with the smart suite, which complicates the process.
Having this feature would greatly enhance security and provide more flexibility for manual integrations. Combining this with a more efficient API technology like GraphQL would significantly improve the usability of SmartSuite as a comprehensive database solution.
Jon Darbyshire
Hello lorenzo! I have a few more questions for you:
- Can you provide examples of the specific solutions/apps you would like to limit access to with the API keys?
- What specific rate limits would you find useful for your use case?
- Could you elaborate on the additional security features you mentioned?
lorenzo
Jon Darbyshire
Personally, I would deselect all tables and solutions by default, enabling access only when necessary. This way, the API key will have access to only the relevant resources. If the API key is compromised, the unauthorized person won't have access to all the data in the database. But in terms of keeping
- For example, consider a table in the database containing customer reviews (this is something we have actually implemented). Let's say you want to display these reviews publicly on your website. However, with the current personal API key, the client can access all tables in the database and has the ability to add, change, or delete records. This poses a significant security risk.
- Regarding rate limits, while not as critical, it’s wise to adjust rate limits to accommodate expected traffic on specific keys. This prevents hitting the main rate limits of your account, ensuring other essential processes remain responsive.
- Additional security features I would think of would be IP/domain restrictions. Since people using this feature would often be building their own applications / frontends that operate from a certain IP / domain.
Stripe serves as an excellent example of this approach, implementing fine-grained data scopes effectively. Similarly, I suggest applying this concept at the SmartSuite table level, and optionally at the solutions level, rather than using predefined scopes like Stripe. See my screenshot for reference.