Current plan level (Free, Team, Business, or Enterprise: Retool pricing): Business (Startup)
Monthly/Annual (if Team or Business): Startup
Question / Description:
I have a ReactJS application that I'm migrating to Retool. In my app, I use the @react-oauth/google library, specifically the useGoogleLogin hook. From its response, I retrieve the 'code' and use it to make backend requests. Is it possible to access the Google 'code' after login in Retool?
When you mention 'code' are you referring to the Access Token that is returned in response to that hook?
Retool has support built in for Google OAuth 2.0 as described in our docs here.
Long story short, once you add in Google OAuth to a Resource which is a layer on top of a Google backend API, the Access Token will be automatically saved to a variable that you can pass along in the Header of the API request which are sent from your Retool app as Queries.
There will be more details on using Google OAuth 2.0 under the Resources Tab when you select OAuth 2.0 as the method for Auth.
What I was actually referring to with “response.code” was the idToken. In the API Resource > OAuth2 > “See token status,” it appears alongside the accessToken and refreshToken.
As I mentioned, your response helped me discover some alternative paths.
What I really want to do is the following:
In my Retool application, I’ve configured SSO with Google, so my users are already logged in with their Google accounts. I would like to obtain the accessToken from their login and use it to authenticate my backend.
With the guidance you provided, I managed to create a workaround by doing the following:
In the header, I added an AuthLogin button, and from there, I call my API Resource with OAuth2 configured for Google. This way, I was able to obtain the token and authenticate with my backend. The downside is that my user has to “log in” twice in the application.
Is there any solution to this? Or is what I’m trying to do too “crazy”?
Great question I believe it would be using the all caps variable which retool auto-creates as OAUTH2_TOKEN same as in the header.
I am curious how you were able to grab the token when you do auth the second time! As I would assume it would be the same.
Retool should save the token under the hood as OAUTH2_TOKEN but if you found a way to manually save it on the second button click auth trigger I would imagine the same process happens when a user SSOs in with Google.
Great testing and thank you for the screen shots they were super helpful for me to better understand the issue.
So the auth does get a little confusing but from what I heard from the team, the token created by SSO is only accessible for Enterprise plan users
Because there can be many resources with different auth providers configured for each, and because permissions for different auth resources can vary by user, by default the user will need to auth in to a resource/query to get a token and use it, even if it is Google's OAuth 2.0 or any other type of auth.
When you want to run a query, clicking a button to trigger the query will prompt the user to 'auth' in to that single specific resource and then the OAUTH2_TOKEN is created and accessible for that resource and it's queries.
If you want to get the token for a users google account and query data without needing user interaction such as a button click.
You can run a query on page load, which will ask the user for the 'second' auth in and this will generate the token needed.
From there, you can chain on further events to this queries successful run to populate your app with other API calls.
But unfortunately the SSO into the app will not have a token that is accessible, I agree it seems redundant but for the reasons I mentioned above, the first SSO is for general app access and the second is for any resource (in this case google) but with Enterprise accounts you have greater control over the first SSO and could avoid the second.
It's much clearer now.
However, the user experience is still quite poor.
The greater control over the first SSO being available only with the Enterprise plan doesn't make sense to me, but it is what we have for now.
The feedback is to provide access to SSO tokens regardless of the plan.
This makes much more sense.
Unfortunately that is what we have for now. Since Retool isn't designed to function as an Identity Provider and Custom SSO was designated an Enterprise level tool by our team.
If your users authenticate to Retool with OIDC-based Custom SSO, then you can configure authentication on your Retool Resource with the ID Token and Access Token fetched during SSO.