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

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@jrieke @kmcgrady this is a follow-up to #12044 that also fixes logout to also properly log out from the oidc provider instead of just deleting the cookie.

I just rebased it to the current development branch, so it should now be ready for review. It's probably better to take this on for you while you still remember the OIDC context :)

Just for clarification: end_session_endpoint is something returned by the OIDC provider, the developer doesn't need to set that manually in their secrets.toml, correct? I.e. this PR doesn't affect our public API in any way, it's only an internal behavior change?

Just for clarification: end_session_endpoint is something returned by the OIDC provider, the developer doesn't need to set that manually in their secrets.toml, correct? I.e. this PR doesn't affect our public API in any way, it's only an internal behavior change?

Yes, this is something that comes directly from OIDC server metadata.

This does affect behavior of course, by properly logging the user out from the OIDC provider perspective as well.

For instance, Frontegg (the provider we use) normally keeps it's on cookie and auto-logs you in when directed to login redirect with that cookie persent. Calling the logout properly clears it's cookie as well, meaning next time you log in, you are presented with a login screen. Which is the expected behavior (and my reason for this PR). I imagine it's the same for many other providers as well.

Summary

This PR implements OIDC-compliant logout functionality by redirecting users to the OAuth provider's end_session_endpoint when available. Key changes include:

1. Modified logout flow: st.logout() now performs a proper OIDC logout by redirecting to the provider's logout endpoint with client_id, post_logout_redirect_uri, and optionally id_token_hint.
2. Provider tracking: The auth cookie now includes the provider field to identify which OIDC provider the user logged in with.
3. Graceful fallback: When end_session_endpoint is not available (e.g., Google), falls back to local logout only.
4. Callback handling: The /oauth2callback endpoint now gracefully handles missing state parameters (for logout redirects) by returning 302 instead of 400.

This addresses the issue where OIDC providers that maintain their own session cookies would auto-login users even after calling st.logout().

Code Quality

Strengths

1. Well-structured code: The new methods _get_provider_logout_url() and _get_redirect_uri() are properly encapsulated with clear single responsibilities.

2. Good logging practices: Appropriate use of logging levels (_LOGGER.info for expected scenarios, _LOGGER.warning for failures, _LOGGER.exception for errors).

3. Proper error handling: The code gracefully handles various failure scenarios (missing cookies, missing provider, invalid JSON, network errors) without breaking the logout flow.

4. Security considerations:

   • Redirect URI is validated to end with /oauth2callback before use
   • URL parameters are properly encoded with urlencode()
   • Cookie values are signed

Minor Observations

1. Line 285-293 in oauth_authlib_routes.py: There's a redundant if provider is None: check in AuthCallbackHandler.get() after the check at lines 253-258. The code path shows this cannot be reached since we return early at line 258. However, looking at the comment referencing issue "Error, missing provider for callback." - phantom error log on st.logout() #13101, this appears to be intentional defensive code for edge cases. Consider simplifying this.

        if provider is None:
            # See https://github.com/streamlit/streamlit/issues/13101
            _LOGGER.warning(
                "Missing provider for OAuth callback; this often indicates a stale "
                "or replayed callback (for example, from browser back/forward "
                "navigation).",
            )
            self.redirect_to_base()
            return

2. Exception handling in _get_provider_logout_url(): The broad except Exception as e: at line 246 catches all exceptions. While this is acceptable for a best-effort feature, consider being more specific or adding debug logging for unexpected exception types.

Test Coverage

Strengths

The unit test coverage is comprehensive and well-structured:

1. test_logout_success_no_cookie: Tests fallback behavior when no auth cookie exists.
2. test_logout_with_oidc_end_session_endpoint: Tests redirect to provider's logout URL with required parameters.
3. test_logout_with_id_token_hint: Tests that id_token_hint is correctly included when available.
4. test_logout_fallback_no_end_session_endpoint: Tests graceful fallback when provider doesn't support OIDC logout.
5. Updated callback test: Verifies provider field is stored in cookie.
6. Updated missing state test: Verifies 302 redirect instead of 400 error.

Potential Test Gaps

The following scenarios are not covered but would be good additions:

1. Invalid JSON in auth cookie: What happens if the cookie value is corrupted?
2. Exception during load_server_metadata(): Network failures or timeouts
3. Missing redirect_uri in secrets: Edge case when secrets are misconfigured
4. id_token is present but empty/invalid: Edge case with tokens cookie

These are minor and the current tests adequately cover the main functionality.

Backwards Compatibility

This PR is backwards compatible:

1. Additive cookie change: Adding provider to the auth cookie is non-breaking. Existing cookies without provider will simply not trigger OIDC logout.

2. Graceful degradation: If end_session_endpoint is unavailable, the original local logout behavior is preserved.

3. Behavior change for callback endpoint: The /oauth2callback endpoint now returns 302 instead of 400 when state is missing. This is intentional and necessary to support the OIDC logout redirect flow.

4. Documentation updated: The st.logout() docstring correctly reflects the new behavior.

Security & Risk

Security Assessment

1. ✅ No sensitive data exposure: The id_token passed to the logout endpoint is per OIDC RP-Initiated Logout specification and is sent directly to the identity provider.

2. ✅ URL injection prevention: Using urlencode() properly escapes parameters.

3. ✅ Redirect URI validation: The code validates that redirect_uri ends with /oauth2callback before use.

4. ✅ Signed cookies: Auth and tokens cookies remain signed and httpOnly.

Risk Assessment

1. Low Risk: If the provider's end_session_endpoint is unreachable, the user's local session will be cleared but they may remain logged in at the provider. This is an acceptable trade-off documented in the updated docstring.

2. No E2E tests: The OIDC logout flow involves browser redirects that are difficult to test without E2E tests. The unit tests cover the server-side logic well, but integration testing would require manual verification or dedicated E2E infrastructure for OAuth testing.

Recommendations

1. Consider adding defensive test for malformed cookies: Add a unit test for the scenario where json.loads(cookie_value) fails.

2. Documentation: The docstring change accurately describes the new behavior. Good job on updating user-facing documentation.

3. No blocking issues identified: The implementation follows OIDC best practices and handles edge cases appropriately.

Verdict

APPROVED: This PR correctly implements OIDC-compliant logout functionality with proper fallback behavior, comprehensive unit tests, and good security practices. The change is backwards compatible and improves the user experience for OIDC providers that support end_session_endpoint. The code quality is high, and the logging/error handling is appropriate for production use.

This is an automated AI review. Please verify the feedback and use your judgment.

Hello @velochy, firt of all, congrats on adding tokens in version 1.53!

However, I encountered a 400 error when calling st.logout():
Your request resulted in an error. The ‘post_logout_redirect_uri’ parameter must be a Logout redirect URI in the client app settings.

Okta configuration:

• Sign-in redirect URIs: http://localhost:8501/oauth2callback
• Sign-out redirect URIs: http://localhost:8501

After reviewing the code, it appears that post_logout_redirect_uri now redirects to the Sign-in redirect URI instead of the application root. As a result, the Sign-out redirect URI must be updated accordingly. This change is noted here.

Two suggestions if I'm not mistaken:

• It would be good to document this behavior in the st.logout API reference.
• Would it be possible to add post_logout_redirect_uri as an optional parameter in st.logout(), with a default value?

@ppo-corp thank you for pointing these things out.

Initially, the redirect URI-s were indeed different, but this led to #12144 (comment)
So I figured it is easier if there is just a single URI that needs to be whitelisted in the OIDC provider (as most providers I've seen have a single whitelist, not two separate ones). Sorry that caused you inconvenience, and yes, it should definitely be documented. Unfortunately I don't really know my way around the protocols of editing the documentation of this project but maybe @jrieke can help here :)

as for making that end point configurable - it seems to not be worth the extra complexity unless there is a very clear need for it. Do you have a use case that the present system does not support at all?

@velochy, thank you for your quick response. Adding this parameter (optional) would offer a little more flexibility on the application side, especially for teams that do not have control over the IdP configuration. Also, since this is a URL parameter that gives the application the choice of redirection, it would be interesting, in my opinion, if this value were not forced by Streamlit.

Perhaps we could also add a parameter named post_logout_redirect_uri to the [auth.xxx] sections of the secrets.toml file, so that developers can see all the options in one place, which is simpler than adding a parameter to the st.logout() function. @jrieke ?