Hi, Avi. Could you please capture everything happening in browser during login and subsequent logout (which fails to kill session at Gluu) with something like **SAMLTracer** plugin for Firefox, or a similar plugin for any other browser, do export of the capture, and share it here? The plugin you'll choose must be able to capture not only headers of HTTP request/response, but body of messages as well.

Was this ever resolved?

I couldn't reproduce it in my test 3.1.1 instance. After calling logout endpoint from RP my oxAuth session is killed and next time I'm sent to authz endpoint I'm forced to log in again. If Avi could share results of capture I suggested and whole contents of `/opt/gluu/jetty/oxauth/logs/` gathered shortly after the issue is encountered, there may happen to be some clues.

That may be unrelated, but I remember having some issues with `gplus` authentication script in latest packages. After the initial authentication, even when I tried to log out, when next time I was sent to login page for a new OIDC flow, if my session at google was still alive, the script won't give me a chance to choose anything, and just immediately were proceeding to log me in. Yet it wasn't completely transparent, it was obvious what was happening. Perhaps you may use some other kind of auth script in your setup, Avi, which now malfunctions in 3.1.1?

Hi Aliaksandr, Thanks for taking the time to try to replicate the issue. Unfortunately, I've had to put the problem on hold for a few days since we were looking to demo some of the stuff that involved our Gluu integrations over the week, so I ended up restoring our last stable 3.0.2 snapshot so the demos could work reliably. I'm working with our sysadmin to get a second server with the 3.1.1 snapshot so that I can get back to using it for development without breaking any potential demos we may need to do. I'll certainly be back with a bit more detail once I have access to the 3.1.1 server again. Thanks for your time and patience, Avi

Thanks, Avi. May I also ask you to elaborate a bit regarding method of migration you used prior to encountering this issue first? >I've been working through migrating our Gluu 3.0.2 box (which we had working in a stable and reliable manner) to 3.1.x Did you use some migration script, or just manually recreated your configuration in the new instance?

Hi Aliaksandr, I used a migration script from [https://github.com/GluuFederation/community-edition-setup/blob/upgrade_script_3.1/static/scripts/3031_Readme.md](https://github.com/GluuFederation/community-edition-setup/blob/upgrade_script_3.1/static/scripts/3031_Readme.md) to upgrade to 3.1.0, then replaced the .WAR files with 3.1.1 when they were available. I experienced the same issue in 3.1.0, however. Thanks, Avi

Hi, Avi. What is the current status of that issue? Are you still keep experiencing it? If you do, do you also use any custom auth script in your setup? If it's the case, may I ask you to share it with us? I also still would like to see the capture I mentioned before. Please use **SAMLTracer** Firefox plugin (or any other similar plugin for any browser, capable of capturing all HTTP traffic, including body of messages) to get a dump of everything what happens during this suspicious flow (initial login, logout, new login attempt which suddenly doesn't require submitting credentials). Please also provide a part of `/opt/gluu/jetty/oxauth/logs/oxauth.log` related to this flow (more or so).

Hi Aliaksandr, Thanks for your patience. I've managed to get our 3.1.1 server back up and running and got the details you requested. The SAMLTracer JSON export is linked. I've obfuscated the actual domain names but made it clear which is the application and which is the Gluu server. The one detail that might be unclear there is the https://application.mydomain.com/logout request. That request calls a simple server side script which performs the following: If there is currently a logged in user in the application's session, 1. Send the end_session GET request to https://gluuserver.mydomain.com/oxauth/restv1/end_session?id_token_hint=(session ID token)&session_state=(session state)&post_logout_redirect_uri=https://application.mydomain.com/home/ 2. Output the response from that request to the browser, which is returning: <!DOCTYPE html><html><head><script>window.onload=function() {window.location='https://application.mydomain.com/home/'}</script><title>Gluu Generated logout page</title></head><body>Logout requests sent.<br/></body></html> 3. Clear application's session. After that, we're correctly redirected to /home in the application and attempt to start the login process again but instead of getting a login screen we're immediately passed back an active session. The only thing I can see in the oxauth.log within the timestamps of these requests are several lines of: INFO [qtp2008017533-18] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:205) - Authentication success for Client: '@!DFE8.29E5.39AE.805F!0001!B7E5.ACFE!0008!308F.160E.C481.7100' Thanks very much for your time and apologies for the delay. Let me know if you need any further details from me - I should be a lot quicker to respond this time since the server is back in my hands. Thanks, Avi

Thanks, Avi. What about a custom authentication script in your setup? Do you use some?

We've only used the 2FA TOTP custom authentication script but it's currently inactive on this instance.

>We've only used the 2FA TOTP custom authentication script but it's currently inactive on this instance. Could you elaborate? What are your current settings at "Manage Authentication -> Default Authentication method" tab? At "Manage Custom scripts" page is "Enabled" checkbox unset for the script?

The Default Authentication Method is using auth_ldap_server for both Default acr and oxTrust acr. The custom script (which was a slightly modified version of the standard HOTP/TOTP authentication module script) is indeed unchecked for the Enable checkbox. One further detail I may have forgotten to mention earlier is that logging out through oxTrust DOES work and kills the session correctly. It's currently the only way we can logout, by going to oxTrust, clicking Logout there, and then refreshing the application page, which then shows the Login screen again, as expected.