🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

@sfc-gh-nbellante this should fix most of this issue, as both bug reports mention adding client_id to url made it work.

One comment by pallagj has me a bit worried though. Seems at least one provider also requires the id_token_hint for this to work. This is currently impossible to provide as it is not stored. I have a PR up that would make that possible too, but it is waiting behind a product manager currently on vacation, and is likely to need quite a few cycles of iteration if he has significant comments.

What could potentially be done is to add a logout_at_provider parameter to st.logout() so st.logout(logout_at_provider=False) would bypass the redirect, allowing the people for whom it is not working to bypass it for the time being. But as I understand it, that too would require product approval and would thus delay the solution, so it might make more sense to just wait out the PR above getting merged in.

Hi @velochy,

First off, thank you so much for your drive and dedication in tackling this feature and the subsequent bug reports. We truly appreciate your thoughtful analysis and your quick work on a potential fix. The ability to properly handle provider-specific logout flows is a valuable addition that we want to include in Streamlit.

Given the number of users impacted by the current regression, our immediate priority is to restore the original, stable behavior for everyone. To that end, we've decided the best course of action is to revert the initial change for now. We will be cutting a 1.48.1 patch release shortly to ship this fix.

This is purely a short-term measure to ensure stability, and we are very keen to bring this functionality back in a future release. We are more than happy to review future PRs that re-introduce this feature, including the one you already have open to store the id_token_hint. Your insight that the id_token_hint is a necessary component for some providers is exactly the kind of detail we need to get this right.

One of the key takeaways here is that identity provider integrations have many subtle differences. For us to ship this feature with confidence in the future, it will be critical to have broader test coverage that accounts for these edge cases.

For transparency, we wanted to share our upcoming release schedule. Once we're all confident in the solution and its test coverage, these dates represent the next opportunities to get this functionality included. There's no rush at all, this is just for information purposes:

• v1.49.0: Code freeze is planned for August 20, release the following week.
• v1.50.0: Code freeze is planned for September 17, release the following week.

Thank you again for your incredible contributions and your proactive communication. We're looking forward to working with you to land this feature!

@sfc-gh-bnisco thank you for the very thoughtful message.

Honestly, in this situation, if it were my project I would likely make the same call. Safer to revert considering the people affected, especially considering it does seem some providers need the functionality that currently cannot be added.

This is a feature I still need for my own project, so don't worry, I'll still be pushing it. But I'll try to get the tokens & refresh PR merged first, as that sets us up for success on this :)