Just want to confirm that this is the behavior that you're seeing: the user is able to authenticate and access the embedded Retool app, but then they are not able to authenticate into a specific resource? If the user accesses the app directly in Retool, they're able to successfully authenticate to the resource? Is this happening for all users?
Authenticating in Retool should be entirely separate from Retool Embed. The Embed URL that is returned from a POST request to get an Embed URL shouldn’t require any authentication; it’s expected that authentication will be handled by the application where you are embedding Retool.
We have a similar scenario. We use OAuth to authenticate with a resource. When using the retool editor / app, the user is able to use our OAuth flow to authenticate to the OpenAPI resource that we have configured and everything works fine. When we use Retool embed with an embed url (that we obtained from making a call on our backend to /api/embed-url/external-user), we get the error Here is the error: JsonWebTokenError: jwt must be provided displayed in the embed frame. We are using the self hosted option. Note that if I open up our retool app and have already authenticated the resource and then refresh the page that has the embed url, it will work fine (because it is already authenticated), but the whole point of embed for us is to make sure that users don't have to login twice. So this at least means the url is valid ... it's just the authentication piece that's not working for embed. Also, I notice that when the retool app is open on its own, when authentication is attempted and viewing the network traffic to retool, a call is made to POST /api/obtainAuthorizationToken that completes with a 200. When the same app is running in embed, the retool call to POST /api/obtainAuthorizationToken fails out with a 401. This seems like maybe a bug within retool?
Hi @Tess ,
The scope for the token was set according to the documentation ("App: Embed").
For me this is happening for a Cloud account.
Actually the issue we are facing is the same as @chris_enter describe it here
Just wanted to clarify a few things here in case people are still trying to use Retool Embed or in case others come across this post
1) We have an internal request to correctly support using Retool Embed with apps that have resources with user based authentication (OAuth). Once this is supported, end users will be able to authenticate using your external auth system to access your Retool pages and then they can do additional OAuth for resources as needed.
2) You can currently authenticate a resource query in a Retool Embed app, such as a REST API query, by passing in an access token from your parent app authentication. You'll add the access token as custom metadata on the current_user & then, in each resource query's headers, you can pass the current_user's token dynamically. It's a bit tedious to set up the dynamic headers for each query, but hopefully, this approach will enable builders who need their queries to return different data based on the app user.
3) For enterprise users that are already using one of our custom sso methods, you may be able to solve your use case without needing to use Retool Embed (more info here) by embedding a direct link for a Retool application. As long as your parent page + the resource instance use the same SAML or OIDC SSO method, you can go ahead and embed your app without using Retool Embed (i.e. Embed your regular app link in an iframe without going through the process of generating a Retool Embed token + creating an embed URL) and still avoid the “double login.” If using an OIDC based Custom SSO method, you can configure Resources to use the access and id tokens from your IdP to authenticate requests (docs).