Hi @apoorv-2204 ,
Retool apps run inside a sandboxed iframe, so browser APIs like window.sessionStorage and the native window.localStorage are blocked. You can’t rely on browser storage in the usual way inside a Retool app.
Instead, use Retool’s built-in state mechanisms:
- Retool
localStorage - Temporary State
- current_user metadata
For example:
localStorage.setValue("key","value1")
Then
localStorage.getValue("key")
will return
"value1".
1 Like
thanks.
What if i have to store a bearer Token what would be the best practice
Hello @apoorv-2204!
If you are using a bearer token, you’d want to store it at the resource level which will then apply your authorization headers when you use the resource in an app/workflow.
If you need to call upon a separate endpoint to obtain the Bearer token, you would use the Custom Auth option and choose the appropriate authorization type:
The return of this would be set with the “Define a variable” option as a next step in the Custom Auth flow:
Then you define the final header setup near the top of the resource settings:
1 Like
I have already tried that, But the issue is after authentication I have to redirect the user to our dashboard home, And Resource auth dont support conditional navigation.
How to proceed further?
I would suggest maybe looking into the current_user metadata as suggested by @Shawn_Optipath. You could also pass the token as a hash parameter to the dashboard URL. These don’t seem like the most secure options and I feel like there is a deeper issue with how you are redirecting your users after authentication but I don’t have enough data points to be sure.
Would you be able to share a generic overview of your process flow for us to investigate what might be the best practice for your use case?
1 Like
we have our own graphql backend which will offer authentication and access control.
So users will visit this dashboard, login via email and password valid with our system which will provide auth Context and access control.
Our system is going to do signup/signin and access control with the graph ql backend
After your signin mutation returns the token, store it in Retool’s session storage with:
localStorage.setValue("authToken", loginQuery.data.accessToken);
Then, in the same success handler (or an immediately following JS block), navigate:
utils.openPage("dashboard/home");
From there you could include that stored token in future API calls either by manually including it in headers:
Authorization: Bearer {{ localStorage.values.authToken }}
Security Notes on localStorage.setValue()
This is scoped to Retool’s UI session — it’s not the same as writing directly to browser localStorage manually in JS (which can have security risks). Within Retool’s context it’s the supported way to persist a small session token.
If you require extremely tight security (e.g., refresh tokens, rotating tokens), you might need a backend token management layer or an identity service as @pyrrho suggested.
1 Like
Are you talking about custom auth on resource? or a custom built loginpage. Kindly take a look at this. It only provides a simple model , but I would like to have custom auth page.
