User Authenticaction

Using Streamlit
,
1

I have configured my Streamlit application for user authentication with MS Entra using the following documentation: Use Microsoft Entra to authenticate users - Streamlit Docs

However, when the login button is clicked and the user logs in, the user is redirected again for log in. It seems that the session is not persisted.

The application is hosted on AKS and I am using the following versions:

  • streamlit==1.45.1
  • authlib==1.5.2

Thank you in advance for any help

2

When a user logs in, a new session is indeed created by design. The reading of the authentication token only happens at the beginning of a session, so logging in creates the cookie, then starts a new session (where the user’s info is read from that cookie and made available in st.user).

Can you verify that your configuration accepts the kind of account you’re using to log in? The example was for personal Microsoft accounts, so you’d need to change the server meta data if you are using a different kind of account, for example. Are there any messages displayed during the login flow about app permissions?

3

PS. I changed the category of the post. streamlit-authenticator is a custom component, but the tutorial is for the built-in authentication feature.

4

This is the code snippet of my simple Streamlit application:

import streamlit as st

if not st.user.is_logged_in:
    if st.button("Log in with Microsoft"):
        st.login("microsoft")
    st.stop()

if st.button("Log out"):
    st.logout()
st.markdown(f"Welcome! {st.user.name} - {st.user.email}")

I have adjusted the server_metadata_url to https://login.microsoftonline.com/{TENANT_ID}/v2.0/.well-known/openid-configuration, so as to accept users from the specific Microsoft Entra tenant. I have not changed the scope, which by default is scope="openid profile email". In the login page, the user is asked for the following:

  • View your basic profile
  • Maintain access to data you have given it access to

However, when the user grants permission and is redirected to the Streamlit app, the st.user.is_logged_in is again false, since only the login button is visible.

5

Hello @mathcatsand ,

Hope all good – any recommendation on debugging the above?

6

I don’t know if this will help at all, but things that I would try to look at:

  • Verify in your identity provider logs that it thinks it is accepting and forwarding the authenticated user.
  • Verify if this behavior is the same on other browsers and other devices.
  • Double check the redirect URL in both your authentication configuration and identity provider (that you have the /oauth2callback path in both).
7

hello @mathcatsand – sharing an update on the above issue:

by running the Streamlit app on localhost , the authentication works as expected. Since it runs on 2 AKS Pods in Production, do you have any idea on what could be the case?

We have already confirmed the following:

  • the user is successfully logged in in the MS Entra logs
  • the problematic behavior is the same across users and browsers (Chrome and Edge tested) – i.e. the user is redirected again to log in
  • the redirect URI is consistent on both the auth config and MS Entra registration

Many thanks in advance :blush:

8

Can you take a read through this GitHub issue and see if any of the diagnostic questions and thoughts shed some light? (Whether or not you have the same root cause, the same questions apply.)

9

hello @mathcatsand, hope all good :slight_smile:

Sharing an unusual behavior: Authentication succeeds when the application URL (i.e., without the /authcallback suffix) is also added as a Redirect URI in the Entra app registration. However, the behavior is not entirely stable—users may occasionally encounter a login loop. Typically, though, authentication succeeds after one retry.

To clarify: the redirect_uri value in secrets.toml remains unchanged and still includes the /oauth2callback path. Meanwhile, the Entra app registration includes both the base application URL and the URL with the /oauth2callback path as valid Redirect URIs.

10

Release 1.46.0 has a couple fixes that might impact st.login, so try updating and see if there’s still that inconsistency. If it’s still behaving oddly, I think you can go ahead and file a bug report at this point since it sounds like you’ll need to get further into the weeds to figure it out. :sweat_smile: