Hi, Arman. Can we have a full uri that can be seen in your screenshot? I wonder if you are passing id_token hint parameter in it. If the hint is passed, then the id_token must be valid and must still be found in Gluu Server's db - otherwise this error is thrown, according to spec (AFAICR this is how it's supposed to work, as explained to me by the developer in charge). The problem is that if session was created long ago, it could already be timed out by oxAuth, and purged from db, with all the tokens tied to it - then this issue may occur.

Hi Aliaksandr, The issue here is when user logout from one of the integrated application is Gluu. The application is sending a end session request to Gluu. And later if user is trying to logout from another application and as they don't have a session anymore they are getting the error. We just want to know if there is any way we can skip this error page. Thanks, Aman Negi

Hi Aliaksandr, Any update on this, as this is a production issue. We would like to get an update if we have any method to prevent this issue.

Hi, Aman. Sorry for the delay. Here are two most probable causes of the issue you're facing: 1. Your application passes "id_token_hint" url query parameter to `/end_session` endpoint - but this token cannot be found in Gluu Server's db/cache as session is no longer existing, and thus it can't be validated. According to the spec - found [here](https://openid.net/specs/openid-connect-rpinitiated-1_0.html) - "When an id_token_hint parameter is present, the OP MUST validate that it was the issuer of the ID Token", also "..If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted". Thus, it turns out, in such case oxAuth behaves correctly, what was also confirmed by the dev team in the past on a similar issue. To mitigate against this, you may choose to not send the "id_token_hint" parameter in end session requests. 2. If you've confirmed you don't send the parameter, but include "postlogout_redirect_uri" parameter instead and still see that error, especially in case when you know that the session has already been ended by another app, it's probably due to the fact oxAuth can't find any session context for that request, thus it can't validate the uri as it doesn't have any idea what client's property it needs to check in such case. I can confirm that behavior and it indeed seems that error oxAuth displays is confusing. You can try to enable "allowPostLogoutRedirectWithoutValidation" option at "Configuration" > "JSON Configuration" > "oxAuth" page, and then add all possible "postlogout_redirect_uri" uri-s that may appear in such request to "clientWhiteList" list on the same page. This will make oxAuth to redirect such requests to the whitelisted uris without any extra validation. Hope this helps.

HI Aliaksandr, The reason for the error page is 1 case as you mentioned: As i already informed, user it already logout from one application and /endsession enpoint is called and its working fine. The issue arises when user tries to logout from another application but now as the user doesn't have the session with Gluu we are getting the error page. Is there any way we can bypass the error page or customize it? I guess it would be best to schedule a call to discuss this? Thanks, Aman Negi

A quick summary of what was achieved during the last call: 1. We managed to partly resolve the issue in dev environment by enabling the option I suggested above (allowPostLogoutRedirectWithoutValidation) and white-listing a few post-logout uri-s which RPs may use during end session flow 2. Aman's team will assess the complexity of the configuration change they'll have to apply to make that work for all of their RPs (there are dozens of them) to use that workaround, and let us know whether it works for them

Hi, Aman. As promised, I I brought up the subject in my talk with the developer once again, asking him whether it's possible to modify that error page. According to him, there is no actual error page in this case, but instead it's just a regular error response from the backend service with a JSON object carrying some additional info, which is then rendered by the browser itself. He also suggested to think about using regular expressions for the whitelist (it supports them), in case you need to add a huge amount of uri-s there. Hope that helps. Let us know about your progress and the current difficulties you're facing.

Hi, Aman. Any news?

Hi Aliaksandr, Update: We have gone with the enabling "allowPostLogoutRedirectWithoutValidation" option in Gluu and whitelisted all the logout URL in the clientwhitelist section. Today only implemented the solution in the dev server will test it. Can you pls keep this ticket open till we move it production server, will update you once done.

OK, please let us know when you move this to production.

Thanks a lot for keeping the ticket open till we move it to production. Last week we moved it to production and the solution is working fine. Will close the ticket now.