Hi 
I’m moving an existing Streamlit app over to the shiny new built-in auth (st.login(), st.logout(), st.user) and have hit a blocker: there is currently no supported way to retrieve the OAuth access-token / bearer token that typical IdPs issues during a login flow.
Why the access-token matters
Many apps needs to call a protected REST API on behalf of the signed-in user.
The API expects a standard Authorization: Bearer <access_token> header.
Without access to that token I have to fall back to a custom streamlit-oauth component, which:
• forces an extra UI step (user must click a “Log in” button every time they open the app);
• prevents me from using the elegant st.user identity object; and
• makes it tricky to customise styling or layout consistently.
What would solve the problem
A read-only accessor (or callback) that stores the token in st.session_state after a successful login would be perfect, for example:
token = st.session_state[“access_token”] # or
token = st.auth.get_access_token() # or
token = st.user.tokens[“access_token”]
…leaving all PKCE / refresh-token handling under Streamlit’s hood just as it is today.
Even a minimal interface—“give me the raw token string plus its expiry time”—would unlock a raft of backend-integrated use-cases (GraphQL, REST, gRPC, etc.) without requiring developers to maintain a parallel OAuth flow.
⸻
Feature request: Expose the OAuth access-token—ideally via st.session_state—once the user is authenticated through st.login().
This small addition would let us:
• make authenticated API calls server-side with full user context;
• ditch third-party OAuth wrappers; and
• keep the clean, idiomatic st.user identity API.
Would love to hear if this is already on the roadmap or if there’s a recommended workaround. Thanks for the fantastic work on the new auth system—adding token access would take it to the next level! 