Discussion on the usability of Platform APIs #9682
Replies: 2 comments 1 reply
-
@danimrangelb Could you provide more context about why this is necessary? Could you elaborate on the use case where you need SSO links only? This restriction is added primarily because the platform app should only be able to control the accounts that it created. I will move it to a discussion for now. |
Beta Was this translation helpful? Give feedback.
-
@pranavrajs We have a main app in which you can go to other different apps of our ecosystem without doing another sign in step, we handle this with internal sessions that can be shared between apps, but with chatwoot we cannot do that (as far as I know). So as a solution we could create the chatwoot (self-hosted) users from our app via API, but we don't want to do that, because chatwoot already has the UI and logic to do it and also because we do want our support platform to be managed only from the support platform (itself). Instead what we want to do is to list already created users on the platform (chatwoot) and assign it (if necessary) to an user on the main app (ours). The idea is to generate this SSO links and take advantage of this functionality to let our users sign in into chatwoot without another form (UI) step. Also this doesn't mean we need it to be limited to SSO login links only, you may be able to login your account with basic authentication too. Maybe I don't have the whole picture here, but wouldn't be better to let the super admin user to decide what the platform app can or not do? I mean by creating granular permissions like with in accounts section, or maybe just asking if the platform app can mutate/access both, platform and API data? Edit: I don't see why this should be a security feature because API Token leak prevention shouldn't be chatwoot's responsibility (if that's the reason of the restriction), instead the platform should provide a way to revoke keys (which currently does) and maybe a under attack mode to temporally restrict API calls in case the leaked source is not identified yet. Keep tokens safe is userswolrd responsibility, for instance, doing calls only from backend o enabling public endpoints that can access authenticated but restricted platform API requests to prevent exposing credentials. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by @pranavrajs in #6611 (comment)
I know this is intended behavior but it doesn't make sense, I mean, normally you have an API to be able to manage all the resources permissible available.
What criteria is used here to mark it as a security reason not being able to interact with non api created stuff?
Couldn't be a better approach applying granular permissions to the platform apps to let the platform know what that token can or not be able to interact? instead of restricting a huge part of the objects that can be needed for integrating with other external applications?
In my particular case I need to create SSO Links for my customers that are already logged in my backoffice app. So I don't think the solution is to create the users from my backoffice app where I don't have a logic and UI implementation which is indeed already implemented on chatwoot, instead I want to assign user already created on chatwoot that can be logged into chatwoot from my main application without doing another sign in step.
Beta Was this translation helpful? Give feedback.
All reactions