OIDC Redirect Issue - Client not authorized

We have just implemented the OIDC module (Community supported v3.3.3) for single sign on with Microsoft Azure. For the most part, this is working as expected. We are using Studio Pro 9.18.3.   We have an isolated issue where some pages redirect the user back to rooturl/index.html.   The pages in question do not appear to be built in any remarkable way in the modeler. Some affected pages have unique URLs and some do not. There does not appear to be a pattern except that same pages always create the redirect loop.   This issue only happens in our production environment (on-premise service). I have SSO running on my local machine (with a different Azure development account) and I do not experience the redirect on the pages.   Using Chrome Console I can see that when the issue happens this message appears in the log: [Auth] The client is not authorized. Request failed with status code 403. Removing token and session.   If I navigate directly to one of the affected pages by pasting the url, the page constantly loops and does not redirect to the home page.    Searching this error will show another mendix question, but this is not the answer as it happens after clearing browser data and across all users. 
4 answers

Putting our On-Premises Mendix application behind a Web Application Firewall (WAF) caused the issue.


The WAF was receiving false positives for SQL Injections. To resolve this issue, our firewall team created exceptions for the SQL Injection rule using:

URL: /xas/
Parameter: params/xpath


The pages that caused this issue all had one thing in common….they used XPATH retrieves with constraints such as [attribute = false()].  It appears that certain XPATH constraints will appear as SQL injection or XPATH Injection according to OWASP.


This article may be the closest related documentation to confirm this was the issue:



Hopefully this helps someone in the future that is having EoF / Generic connection issues when your Mendix Application is behind a WAF.




Could you check the browser version of those users? If those users use Chrome or Edge let them try the incognito mode. If that works they should check their plugin / extensions. We had issues like this the last couple of weeks. We have not found yet out which extension is causing this but it was solved by using the incognito mode or removing all the extensions they had. Some end clients of ours encountered this but we could not reproduce it ourselves. I had it only once on my local machine and created a support ticket for this. But we have yet to find to root cause.





I no longer believe the issue is related to the OIDC module. The issue occurs whether Single Sign On is enabled or not. I have isolated the issue to only be reproduced when the application is running on my on-premises server. I cannot reproduce the issue on my local dev environment or our mendix cloud dev server.

Our on-premises server was recently put behind a web application firewall, and now believe this may be part of the problem.


I have found that the Mendix Service Console is reporting a connector and M2EE error when the page fails and is redirected to the users home page navigation microflow.


Connector: org.eclipse.jetty.io.EofException: Early EOF


M2EE: Could not get response writer in order to close it

org.eclipse.jetty.io.EoFException: null

Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host



Has anyone experienced issues using Mendix with a Web Application Firewall?


Disabling the WAF has removed the error and resolved the issue. Our WAF team is now investigating logs to see if there is a fix.