Granular API Access with Scoped Permissions
Ivanna Parra
Currently, the Helpjuice API uses a single API key for authentication, which grants full permissions (Super Administrator access). This approach does not follow the best practices of least privilege, as it requires customers to either grant full access or rely on workarounds like proxy servers to implement more secure, permission-based access.
Requested Features:
- Ability to create API tokens with scoped permissions, allowing customers to restrict access to specific resources (e.g., read-only access, limit access to certain articles or categories).
- Option to configure custom API roles with granular access, following the principle of least privilege.
- More control over the permissions granted to API keys, ensuring they are tied to the access level of the associated user.
This feature would significantly improve security and flexibility for customers using the Helpjuice API in more complex, secure integrations.
Matthew McGarity
If feedback is needed on a design:
- API keys (tokens, etc.) should be associated with users, not be a global asset associated with the application in whole
- Actions taken using those API keys should be logged in association with the user.
- No action can be performed with the API key that the user themselves could not perform within the application UI
- API keys can be invalidated and/or rotated separately from the user's access
- If the user's access itself is revoked (ex: employee termination), all of their API keys are immediately invalidated
- The ability to generate API keys should be RBAC-controlled, as organizations may wish to control who interacts with their systems and/or be sensitive to costs & operations
- Ideally, users and/or organizations can define lifetimes for the API keys, after which they naturally invalidate after X number of days, months, etc.
Source = me, an API product manager
Ivanna Parra
Merged in a post:
Limit API Key Access
Steve Tapley
When using the API in a WebApp, the API key can potentially be compromised and used in an malicious manner.
If someone managed to get hold of our key (not that hard for a WebApp), they could easily destroy our HelpJuice instance. API V2 wasn't too bad, since it was read-only, but API V3 allows some very powerful operations.
I would like to have a way for us to specify that a key could perform GET operations only thus avoiding a potential security issue.
Ivanna Parra
Merged in a post:
Restriction on API based on View/Edit Permissions
mehak test saleem
Right now HJ API key which is associated with account owner privileges, so when API key is shared anyone can use it and do the modification. is there a way we can restrict privileges? e.g. some users can only use view only APIs and some users can use edit APIs? Furthermore, API behavior should be like some users can access only articles and others can access users/admin settings?
Matthew McGarity
+1 on this. We have an internal application which would like to ingest our KB content on a regular basis. However, as a cybersecurity company, we cannot in good conscience grant this form of API access, as it goes against the principles of zero trust + least privilege.
Matthew McGarity
+1 on this. We have an internal application which would like to ingest our KB content on a regular basis. However, as a cybersecurity company, we cannot in good conscience grant this form of API access, as it goes against the principles of zero trust + least privilege.
Anurag Nilesh
+1 had submitted a similar idea to have separate API keys with granular permissions.