Context: I’m building an internal application for our organization, and we’re currently on the business plan. I manage user privileges using Retool’s built-in groups and permissions, but I’m wondering about best practices for user authorization.
Right now, I set the application as the landing page of the groups that are using it. They log in through Retool using the built-in login, and once authenticated, they can access the app directly.
However, when it comes to authenticating API requests for resources consumed through the interface, they would need to re-authenticate to make sure to get individual tokens.
The only way to do it, for what I understand, would for users to log into Retool, then log into the application again via a custom login page. In my organization this won't be feasible UX-wise.
Goal: Aside from using shared API keys to authenticate resources (which we don't want to use) , is there a way to enable users to log in just once—whether in Retool or the application—(and without needing the Enterprise plan) but be able to authenticate individually?
Am I missing something? This seems like a standard request, but I couldn’t find clear guidance in the documentation.
How many resources do we need to authenticate our users for?
What type of resources are these?
What type of authentication do we need for these resources?
On the other hand,
Users of your organization should only need to log in once to access your apps. If we are setting up External Apps for external users, we can set up a custom login page, but it sounds like you are building this app for internal users.
Yes it's an internal app and the goal is to have the users authenticate only once via retool authentication since I already handle permissions and groups via retool.
To answer your questions:
How many resources do we need to authenticate our users for? -> Not sure I understand what you mean but we're talking about letting user consume several endpoints of the same REST API.
What type of resources are these? Custom Rest API Endpoints (meaning we design and expose the API so we have 100% control)
What type of authentication do we need for these resources? As long as we can use individual expirable tokens we're open to consider options (user+pass, OAuth2.0, etc.)
Yes exactly @Paulo. Given that I'm de facto already managing users and permission via retool, it would be the more natural step but I can't find information about it. I don't see the token as a property of the user object.
Retool is not built to work as an identity provider. But as a workaround, we could pass in {{ current_user.email }} to identify users and modify the API server to respect that. It's not a form of authentication but it does help identifying the user.
thanks for the reply @Paulo. That won't do unfortunately though since. as you said it's won't be authenticated and we need to authenticate somehow.
But what I fail to understand is what's the best Retool practice here? I mean I'm sure I'm not the only nor the first one that need the resources to be authenticated individually for security reasons.
Our goal is to have the users login once and not have to first create the retool account and then the app one. There must be a "canonical" way to do it no?
Also, calls of the resources in Retool are handled by Retool's servers, not the front right?
We support many types of API Authentication, including Custom Auth. The best practice is to set up the preferred authentication type for the resource, and if needed, a refresh auth workflow and an auth trigger.
The fact that your users currently have to go through 2 logins/sign ups makes me think that there might be a setup issue. Perhaps we set the custom login page as the landing page for that user group. The custom login page is automatically the first page they see when they navigate to any app within your org but they're not logged in yet (with the exception of public apps). If this is the case, set the landing page to be the app you intent to show after login and that should make it so they only have to login once.
Also, when creating a custom login page, do not add an event handler to navigate the user after a successful login. They'll be automatically redirected to the landing page.
