Are you sure the scheme is the same (i.e. https v. http)? Can you post your client config?

Yes, the scheme is the same: Here is the client config. ``` OPENID CONNECT CLIENTS DETAILS ------------------------------ - **Name:** support_portal - **Client ID:** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - **Subject Type:** pairwise - **Expirattion date:** Sun Jul 23 00:00:00 UTC 2119 - **ClientSecret:** XXXXXXXXXXX - **Application Type:** web - **Persist Client Authorizations:** true - **Pre-Authorization:** false - **Authentication method for the Token Endpoint:** client_secret_basic - **Logout Session Required:** false - **Include Claims In Id Token:** false - **Disabled:** false - **Login Redirect URIs:** [https://<our_jira_servicedesk_instance>/plugins/servlet/oauth/callback] - **Scopes:** [openid, email] - **Grant types:** [authorization_code] - **Response types:** [code, token, id_token] - **Post Logout Redirect URIs:** [https://<our_jira_servicedesk_instance>] ```

Hi. As Michael already has said, please make sure post-logout uri you add in properties of this client in web UI is the very same one that your app uses when calling `/end_session` If this won't resolve your issue, please record a HAR file of the whole failing logout flow, and share it with us. You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page.

And what is the request the client is sending?

Here is the client config: ``` Select Application: (required) Custom OAuth App Name: support_client Client ID: (required) XXXXXXXXXXXXXXXXXX Client Secret: (required) XXXXXXXXXXXXXXX Scope: openid email Authorize Endpoint: (required) https://<gluu_instance>/oxauth/restv1/authorize Access Token Endpoint: (required) https://<gluu_instance>/oxauth/restv1/token Send Parameters in Token Endpoint: Http Header Get User Info Endpoint: (required) https://<gluu_instance>/oxauth/restv1/userinfo Fetch Groups Endpoint: Enter fetch group info endpoint. **Logout Endpoint: https://<gluu_instance>/oxauth/restv1/end_session ** Enter the Logout Endpoint of your OAuth/OpenID Provider. Leave blank if logout endpoint is not supported by provider. e.g. If Keycloak Logout Endpoint is configured then on Jira logout you will get logged out from Keycloak too. Use State Parameter: Checked. If checked, state parameter will be added in the authorized server request. ```

If you check the apache httpd logs, you should see the exact request the client is making. You can also turn up the debug logging in oxauth to get the exact request that was received by the Gluu Server.

Here is the excerpt from the Apache log that you asked for. ``` <gluu_server_uri>:443 99.99.99.99 - - [27/Jul/2019:11:04:16 +0000] "GET /oxauth/restv1/end_session HTTP/1.1" 200 975 "https://<client_uri>/plugins/servlet/oauth/logout?application=jsd&return_to=%2Fservicedesk%2Fcustomer%2Fuser%2Flogin%3Fdestination%3Dportals%26logout%3Dtrue" "Mozilla/5.0 (Linux; Android 9; Pixel 3 XL) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.143 Mobile Safari/537.36" <gluu_server_url>:443 99.99.99.99 - - [27/Jul/2019:11:04:16 +0000] "GET /favicon.ico HTTP/1.1" 404 701 "https://<gluu_server_url>/oxauth/restv1/end_session" "Mozilla/5.0 (Linux; Android 9; Pixel 3 XL) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.143 Mobile Safari/537.36" ```

Another important point I missed out earlier. I configured the client as a "Custom OAuth" client (vs custom openid client). Not sure how relevant this is to the current conversation, but thought you should know. When I configure the client as a custom openid client, the retrieved scopes do not have any relevant information (like email etc that I request).

@Michael.Schwartz Is the above excerpt what you were looking for?

Hi, Sved. (Not answering on Michael's behalf, but as he's often busy with management duties, his answer may be delayed, so I'll try my best meanwhile) Regarding the "Custom OAuth" vs "Custom openid client" - I would use the latter if your intention is to employ OIDC. Why it doesn't return user claims for you is a different question. Have you tried to follow Michael's suggestion in [this post](https://support.gluu.org/authentication/7289/post-session_end-error/#at50341) to see what your RP actually passes to Gluu Server? Basically, you need to look into data that is actually being passed back and forth, compare it to OIDC specs and/or your general knowledge of what should be there, and figure out what is missing. You also can resort to my suggestion of [capturing it all in a HAR file](https://support.gluu.org/authentication/7289/post-session_end-error/#at50334); you can view it [here](https://toolbox.googleapps.com/apps/har_analyzer/) then. Overall, I would suggest to provide more detailed data as we need to understand what's going on. We need to see actual requests and responses, and detailed `oxauth.log` at DEBUG level (changed at "Configuration -> JSON Configuration -> oxAuth" in web UI, `loggingLevel` property). That would most likely mean some information regarding your infrastracture may be disclosed (I see you try to obfuscate it in your posts), but that's an inevitable trade off, unfortunately, if you need our help with that project.

@Aliaksandr.Samuseu Thank you so much for taking time to guide me through the next steps that'll help. You are right that I tried to obfuscate the data I am putting out, since they are production servers and I try not to call unnecessary attention to them. However, in the interest of this issue, I will have my team build a temporary server (for both Gluu and Jira with the miniOrange plugin). This will take a few days, but will be done, so you can have all the logs you need to see if there is anything to be done. For now, however, I fixed the issue (spit and glue fix) where I customized the logout code in the plugin and inserted a 1x1px iframe with source as the end_session endpoint. That way, the endpoint is called thereby ending the session for the user and the generated error is, kind of, hidden from the user. Good enough for us, for now. I totally understand the need to understand the standard, but am under a heavy time crunch and hence keep postponing it. The requirement is simple: We have a standalone Jira server and a standalone Gluu server for our users. I wanted to implement Single Sign-On (in a very primitive sense) so the users don't have to create a separate password for our Jira server (they already have an account on Gluu server for other purposes). The only way to have Jira engage an OpenID Connect / OAuth2 server is via a plugin and miniOrange plugin came out to be the most recommended one that a lot of people seem to use. Hence I went down that path. Everything was fine, until I hit the Logout button, the plugin's logout endpoint was invoked. This endpoint logged out from Jira session, and simply invoked the logout endpoing of the OP provided without waiting to hear back from the OP endpoint. Since I was using the end_session endpoint (and did not know how to use the front-channel-logout), Gluu seems to be throwing that error after ending the session. So, like I said, I will have new servers spun up just to replicate this issue and provide all the logs you'd need to see if anything on Gluu's side needs to be fixed. Same for mini Orange team. The end goal is to make this plugin work with Gluu server for the community's benefit.

Just an idea, but when I url-decode the apache log you sent, I see it's ``` https://<client_uri>/plugins/servlet/oauth/logout?application=jsd&return_to=/servicedesk/customer/user/login?destination=portals&logout=true ``` That does not match : ``` Post Logout Redirect URIs: [https://<our_jira_servicedesk_instance>] ```

I tried that URL as well, with the same result. I have asked my team to setup a server to test this out, this week. Will keep you posted and be able to give you detailed logs for them.

Hi, Swed. Any updates on this one? Tickets staying inactive for too long are usually closed. Let us know whether you still need our assistance with this issue.