Checklist

• I have searched the existing issues for similar feature requests.
• I added a descriptive title and summary to this issue.

Summary

We're soon launching native authentication in Streamlit (see #8518). One thing we left out for now is handling errors that appear during the OAuth flow. It would be great to either handle them automatically (e.g. by showing a dialog or toast) or exposing them programmatically.

Why?

These errors should be very rare in Streamlit because many errors are handled directly in the OAuth flow by the identity provider and most possible errors that are propagated back to the app are due to a) wrong configuration (which we usually catch before even initiating the OAuth flow), b) wrong implementation (which we control), or c) the server of the identity provider being down (which shouldn't happen often for the major providers).

But errors can still happen – the most prominent example we found during testing is when the user clicks "Cancel" on the consent screen shown when logging in for the first time. And there might be others we didn't think about yet.

How?

Two possible ways:

1. Automatically show a dialog or toast with the error code and potentially error description and error URI. Note that OAuth recommends showing a custom error message to the user instead of showing the error code and error description directly. But I think in our case (where these errors are very rare), it might be fine to just show that and not require the developer to implement it themselves. We should probably have a parameter on st.login to disable this automatic notification in case the developer wants to handle the error themselves (see 2).
2. Expose the error details programmatically. One way would be to put it into st.user as keys error, error_description (optional), and error_uri (optional). In that case, we should automatically clear these items on the next rerun, otherwise it becomes very hard to only show the error when it happens. Another possible approach would be to have an on_error callback on st.login. But a) we'd need to pass the error details to this callback, which would make it work a bit differently than our callbacks (currently) work and b) it's a bit more cumbersome to work with this in practice because you often have to stick the error message into st.session_state if you want to show it somewhere within the app.

Additional Context

No response