Streamlit Cloud + Auth0 callback failures started recently

Community Cloud
1

I am looking for guidance on a recent auth regression with Streamlit Community Cloud + Auth0.

This setup was working fine until about two days ago, then started failing on callback with:

authlib.integrations.base_client.errors.MismatchingStateError: mismatching_state: CSRF Warning! State not equal in request and response.

What I found

  • Updating redirect_uri to the Community Cloud callback route format (the hosted path-prefix form, i.e. .../~/+/oauth2callback) and matching it exactly in Auth0 Allowed Callback URLs was necessary. before it was just … /oauth2callback

  • Localhost auth flow still worked; hosted flow was the problem area.

  • Pinning streamlit + Authlib to specific versions made behavior consistent, but I don’t consider hard pinning a real long-term solution: streamlit==1.56.0 Authlib==1.6.11

Current status

  • Callback path mismatch seems to be one root cause.

  • There still appears to be version sensitivity when requirements are left unpinned.

  • No auth logic changes were made in app code right before this started.

Question

Could this be related to a recent Streamlit and/or Authlib release?
Has anyone found a robust setup for Streamlit Cloud + Auth0 that works without pinning both libraries to exact versions?

Any recommended version constraints or official guidance for production Cloud deployments would be appreciated.

2

Welcome to the Streamlit community and thanks for the detailed question! :tada: You’re not alone—recent changes in Streamlit Community Cloud and Authlib have caused callback and state mismatch issues, especially with Auth0 and other OIDC providers. The root cause is often a mismatch between the deployed app’s callback URL (which now uses the /~/+/oauth2callback format on Community Cloud) and the Allowed Callback URLs in your Auth0 settings. This path must match exactly, or you’ll see CSRF/state errors on callback. Localhost (/oauth2callback) still works because the path is simpler and doesn’t have the Cloud’s path prefix.

For production, Streamlit recommends always pinning both streamlit and Authlib versions in your requirements.txt to avoid unexpected breakages from upstream changes. This is especially important on Community Cloud, where dependency resolution can otherwise auto-upgrade packages and introduce incompatibilities. There is no official guidance for a “floating” version setup—pinning is the best practice. After updating your callback URLs and pinning, reboot your app to ensure the new dependencies are installed and the callback path is recognized. For more, see the official docs on dependencies and callback URLs and authentication with Auth0.

Sources:

1 Like
3

What happened: Streamlit Community Cloud changed how hosted OAuth callbacks work on their servers (behind st.login). That rollout happened last week with no advance notice. Auth0 sends users back to a fixed callback URL; if it doesn’t match what Streamlit expects exactly, hosted login fails—even when app code didn’t change.

What I did: I aligned Auth0 Allowed Callback URLs and each deployment’s Streamlit Cloud secrets (redirect_uri) with Streamlit’s current hosted pattern:
https://<your-app>.streamlit.app/~/+/oauth2callback

I used these in requirements.txt:
streamlit[auth]==1.56.0
Authlib==1.6.11