You are right to push back, and the answer is that my one-line summary of our problem was misleading.
We did provide the provider's main URL — the configuration has provider = https://login.microsoftonline.com/<tenant>/v2.0 — and the discovery document is complete and correct; it returns end_session_endpoint = https://login.microsoftonline.com/<tenant>/oauth2/v2.0/logout. The provider logout was in fact being called: our log showed two requests to that endpoint.
The loop we were chasing was our own fault, not the extension's. We had set logoutEndpoint to /bin/view/Main/ while the wiki denies all access to unauthenticated users (authenticate_view = 1). So the sequence was: logout, redirect to Main, access denied for guests, redirect to the provider, immediate re-authentication — with a post_logout_redirect_uri nesting one level deeper on every round. Pointing logoutEndpoint at a page that is reachable without authentication (our local login form) fixed it. In hindsight the mechanism was working as designed and the problem was the post-logout target.
Why I touched logoutMechanism at all: while diagnosing that loop it looked like a switch for the logout flow, and it is offered as a settable field on the configuration object. That was a wrong turn on my side, and it is exactly why the dead property is misleading.
One thing I cannot tell from our side: whether the provider session was actually terminated. Our clients are Entra-joined Windows machines, where a subsequent authentication can succeed silently through device SSO, so "logged in again without a prompt" does not by itself prove that the logout at the provider had no effect.
If it helps, I can re-test on our instance with logoutEndpoint left empty (so discovery is used) and post the full redirect chain from the logs.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
