Hi,
We were looking forward to the recent addition of st.login, since proper authentification always plays a big role in our apps. However, we were disappointed by the decision to not return the access token, that usually comes during such an authentication process.
As noted in the API docs:
If the provider returns an access token, that token is ignored. Therefore, this command will not allow your app to act on behalf of a user in a secure system.
Why not? Shouldn’t we let the token issuer decide, what rights that token possibly grants? By not returning the access token, many workflows are simply not possible.
I wish there was an option to return the access token as well, let the developer/organization decide how they handle tokens.
I would like to hear some thoughts from the streamlit devs! Thank you in advance.
Best regards,
3 Likes
I completely agree—returning the access token in st.login would be a very useful enhancement. In fact, I’ve created a GitLab issue for this
1 Like
Totally agree. We will need the generated access token for calling the downstream APIs.
Agree as well. I just posted a request to allow the LOGIN() function to take an optional callback function. The callback function would be invoked when the auth provider sent a response back to the /oauth2callback URI. Having this optional function should allow the developer to decide how to handle the response…including processing the access_token and making additional calls needed to complete the process.
Without it you have to have the auth provider send response to some other (Flask, etc.) server which can then redirect back to the client…but this is ugly because it causes another window to open.