Resource management SSO stuck in redirect loop with Azure AD

We’re implementing Azure AD SSO for our resource management portal and hitting an infinite redirect loop. When users try to log in, they’re redirected to Azure AD, authenticate successfully, but then get bounced back to the login page instead of landing in the application. Browser console shows:


Error: Redirect URI mismatch
State parameter validation failed
Cookie: JSESSIONID not set

This is blocking resource allocation workflows for our production floor. I suspect it’s related to session cookie handling or the OIDC redirect URI configuration in our Azure AD app registration, but I’m not sure where to start troubleshooting. Anyone successfully configured Azure AD SSO with Honeywell MES 2023.1 resource management?

Don’t forget to check the clock skew between your MES server and Azure AD. OIDC state parameters have timestamps, and if your server time is off by more than a few minutes, Azure will reject the state validation. Run ntpdate or equivalent to sync your server time. Also, enable debug logging in your SSO configuration - set oauth.logging.level=DEBUG - and you’ll see exactly which validation step is failing in the redirect flow.

Yes, the JSESSIONID issue is likely your culprit. Azure AD redirects happen across domains, and if your cookies aren’t configured with the right SameSite attribute, modern browsers will block them. Check your Tomcat or application server configuration - you need to set SameSite=None; Secure for the session cookie. Also verify that your MES instance is configured to accept cookies from the Azure AD domain. In the oauth.properties file, look for a cookie.sameSite setting and make sure it’s properly configured for cross-origin requests.

I’ve seen this exact issue. Beyond the SameSite cookie problem, you also need to check your Azure AD app registration’s token configuration. Make sure ‘Access tokens’ and ‘ID tokens’ are both enabled under ‘Implicit grant and hybrid flows’. Honeywell MES 2023.1 expects both token types in the OIDC flow. Also, verify your app’s ‘Supported account types’ setting - if it’s set to single tenant but you’re testing from a different tenant, that could cause validation failures.

Classic symptom of redirect URI mismatch. In your Azure AD app registration, you need to add the exact callback URL that Honeywell MES uses. It’s usually something like https://your-mes-server/resource-mgmt/oauth/callback. Check the MES SSO configuration file for the exact redirect URI it’s expecting, then make sure that exact string (including trailing slash or lack thereof) is registered in Azure AD under ‘Authentication’ → ‘Redirect URIs’. Even a small difference like http vs https will cause this loop.

I verified the redirect URI in Azure AD matches our MES configuration exactly: https://mes.ourcompany.com/resource-mgmt/oauth2/callback. Still getting the loop. The ‘State parameter validation failed’ error makes me think there’s something wrong with how the session state is being maintained between the redirect to Azure and back. Could this be related to the JSESSIONID cookie not being set properly?