Streamlit Next.js Component, Auth0 Authentication, Bi-Directional Messaging & Serverless APIs

Hi - I’ve been doing a fair amount of investigation on the use of components as a way to integrate Auth0 authentication into my Streamlit apps (I need this for work and our clients). It wasn’t until components allowed CORS settings recently (>=0.74) that I started having some success (i.e. making it simple). I spent some time over the past week completing my experiments and am happy to share the implementation and detailed documentation. A shout out to @tim @randyzwitch @andfanilo @ash2shukla for earlier discussions that helped me along.

For a quick heads-up here’s the PDF documentation, and here’s the repo (replacing the older original version I had made).

As usual your code improvements and comments are most welcome as we hone our skills using awesome Streamlit!



Awesome stuff @asehmi !

1 Like

That’s some very thorough documentation there :heart_eyes: will have a deep look soon
Thanks for the write-up!

1 Like

Really impressive asehmi! :raised_hands:

1 Like

Hey @asehmi,

Wonderful! :star_struck:

Happy Streamlit-ing!
P.S. I’m just going to switch you topic tag from using Streamlit to Show the community so people will have a easier time finding your work in the future!


Yeah, you’ve helped me a lot so it’s payback time. Would love your input and improvements @andfanilo.

1 Like

window.localstorage worked a charm. Thanks!


Perfect, thanks!

1 Like

Some cool Streamlit apps you have on your site Charly.

1 Like

Thank you! More coming soon! :slightly_smiling_face:

Hi @Marisa_Smith @andfanilo

I’ve updated the Auth0 integration component and built a sample app. The repo and docs have been updated. Here’s a demo:

Code for the component is here:

1 Like

NOTE: Due to browser security restrictions the embedded iframe used in this solution doesn’t work in a production environment because the login providers (like Google, Microsoft) do not allow their login screens to be parented by an iframe.

I’ve modified this implementation to use a popup login window instead, and cleaned up the code [NOT released yet, but plan to soon]. Popups have their own problems, but it now work in Heroku. Remaining issue is that not all users allow localstorage (or indexeddb, websql) which is required for the transfer of credentials from the IdP login app, via the st component app, to the st app.

Honestly believe the simplest solution will be to use a centralized membership/authentication database.

Here’s a gif of the latest version:


Hi Arvindra, @asehmi

Many thanks for the update. We will be waiting for the updated code. Do you know when it will be available? Could you clarify the following points in meantime, please?

  1. How .env.local need to be exported?

NOTE: I have .env.local in the root directory, but it seems to be not used by environ. So I was exporting variables manually.

  1. Could you clarify the following variables, please?
# API Client
#<---YOUR AUTH0 DASHBOARD--->/settings
API_CLIENT_NAME = '<---X--->'
API_CLIENT_ID = '<---X--->'

@Andrei_Volkau you need to set up an Auth0 account then go to the account set up a SPA connection where you configure these settings. Try Auth0 for FREE. Make sure you set up “Allowed Callback URLs”, “Allowed Logout URLs”, “Allowed Web Origins”, “Allowed Origins (CORS)” as you require for the settings in your frontend component app.

I’ve update the repo.

If you want a demo/walkthrough then contact me with a zoom link (I’m based in Oxford, UK).


Hi Arvindra, @asehmi

Thank you. I just emailed you. You might want to change the environment variables listed in README since many of them are renamed now.

Hello @asehmi !

Great work on Auth0 component! It would be good to update the repo with such a fix if possible. The cross-talking issue unfortunately prevents normal usage of the component. Sorry, not have enough skill to make a pull request with such a fix. It would be really cool to finalise the component while fixing this issue.

1 Like

@p0povaalesi I’m keen not to swap out Auth0 (it’s an amazing product) and the st app will always need to store the identity (or a key of some sort) in session state so it can retrieve user auth permissions when required from the DB or whatever cloud identity provider solution is used (Auth0, Okta, Azure, Google, etc.). This is why I’m keen that Streamlit provides native session state, rather than the workaround being used.

  • The st host app can’t initiate a communication with the embedded web component (except once when it is mounted), so it can’t “ask” it for the session.
  • If instead the st app calls a web API of the component, that requires a user token identifier, so isn’t of any use.
  • We can’t use cookies, as the st app and the component run in different domains so can’t share cookies.

The only way I can see to seamlessly share an identity token is to hold it in st session state.

I do have another solution, unpublished at this time which uses a centralized DB. In this solution (which doesn’t use st components) I have an extra step post-login, which returns a one-time expiring unique code to the user who then exchanges it for their auth tokens. But still, this code and exchanged tokens need to be stored in session state, so you’re back to square one! My current solution removes a lot of friction.

If you use what I’ve released and simply force the user to login immediately every time they open your app, then session cross-talk shouldn’t be an issue.


Hi everyone -

Secrets management is now available in Streamlit sharing! You need to upgrade to version 0.80 of Streamlit, the temporary documentation location is linked below.


1 Like

Hi - very handy randy! :slight_smile:

I can use this for Auth0 config for sure. Just need a native session state management and we’re golden.



Nice, very cool.
I like to implement the login using google auth but still not sure how to glue it all together. Would need your help.