Users get redirected to /Users module when refreshing their session

On occasion when a user refreshes their session, they get redirected to the /Users module, which presents them with an Invalid Permissions screen (since end users do not have access to the Users module). I am at a loss trying to debug and figure out why this occurs. This occurs in both Traditional and Reactive apps, and is completely random when it occurs.

I want to know a solution to prevent SAML from attempting to redirect unauthorized users to the /Users module and instead back to the app that initiated the refresh, or at the very least provide a default location that all registered users have access to (our intranet site or our central app dashboard landing page).

Secondly, I would greatly appreciate if someone could help explain or provide a link to a document that explains the flow of the login. It's my understanding that a request made goes to the OutSystems SSO first <https://[customer domain]/Users/SSO.aspx> from here it goes to the defined IdP server Single Sign-On URL. This should return back with the signed in users session, which OutSystems should then load in the original URL that the request was made from. Looking over the SAML messages log in the /Users module, I can see every request has the "Related URL" correctly set as the source app, yet on occasion they are not getting redirected back to this related URL and instead something entirely different which doesn't make sense to me.


It's hard to say without seeing the exact logic of the applications in question, however, it sounds like you may be hitting an error page (likely a permissions error because they're no longer logged in if their session has expired) which is causing the problem.

There are a number of built-in error pages and error handlers that will either redirect the user to a login screen or an error page related to permissions.

I would first check the logs via service center for any errors and verify that the user is not encountering any permissions based errors. If they are, you can see which screen it is happening on and follow the error handler logic along to the place where they're getting redirected away from your SAML login and correct the issue.

If you have more information or would like to share the module we are happy to assist!

RAD Manage

The login flow is the standard flow that is outlined in OutSystems docs and what every support answer shows. That is to say the global exception handler catches the SecurityException, if the user is logged in redirect to No Permission screen, otherwise get the User_GetUnifiedLoginURL and redirect the user to that. This is all using OutSystems built in functions and nothing has been modified.

Like I previously mentioned, the SAML response logs all show the correct related URL, yet sometimes users get redirected to a different URL, which is the "/Users" modules when they should be getting redirected back to the source app "/The_Insider" (for example).

I have attempted to log the response from the GetUnifiedLoginURL, but its useless as the Destination URL appears to be encrypted (cut off the remaining portion just in case)

It's my understanding that whatever the OriginalURL evaluates to is what the end user will be redirected to, which should never be the "/Users" module.

Hi Alexander,

I am seeing the same issue with SAML 2.0 integration.

There are no error logs and the SAML logs look good, but intermittently, users do not get redirected to the main application after login at the IDP, and get presented with the Users application.

I am lodging a support ticket about it now (which is how I found this post, thought I'd search for answers first!).

Something I did notice, which I am going to try (difficult though when its hard to reproduce the issue) is setting this site property in the Users module: AlternativeSamlLoginLogoutFlow to True.

I noticed in walking through the Users module code (opened a cloned version to see it), that there is the following comments in SAMLAuth/DoLogin/Preparation and SAMLAuth/DoSLOLogout/Preparation:

"RPM-1077: tentative workaround for login requests when there is an active session on Users. Prevents redirects to Users screen."


"RPM-1077: tentative workaround for logout requests when there is no active session on Users. Forces a logout instead of redirecting back to the application."

This flag only appears to take effect when on logging in, there is already a logged in user; and on logout, the user is already logged out.

I hope this helps. I'll post again if I find something that works.

Kind regards,


Hoping to hear a solution from your support ticket with OutSystems. We still have end users on occasion getting redirected to the Users module when trying to refresh their expired sessions (logging back in or refreshing the page).

Hi Alexander,

Yes we've just added more logging, and the OutSystems team is investigating.

Kind regards,


I'll have to keep an eye on this. Agreed its near impossible to test since it can't be reproduced at will. It appears to be random chance on when trying to log back in after a session time outs.

Hi Alexander,

Actually I noticed something I had forgotten when walking through our code.

In our code before we attempt to retrieve the Unified login URL, if there is a user already logged in (eg maybe they logged in on another browser tab), it will log the user out first.

Maybe try these steps

  1. Ensure there is no user logged in
  2. Login to the application as normal
  3. Open another browser tab
  4. Go to a page that will take you to the unified login URL. Though, your app may not have this. If you don't have this, these steps will be impossible to reproduce. So if you don't have one, maybe create a page temporarily with a button "Go to login" tat gets the unified login URL and redirects to it.
  5. The app should redirect to the IDP, then immediately back to the app, as there is a logged in user, if not, go through the login steps.

I suspect this will take the user to the Users app instead of the main application.

Hope this helps!

Kind regards,


Hello Alexander,

I have some good news. We have resolved our issue.

The problem was that even though we had reduced the React Web App session timeout (Max. Idle Time) to 15 minutes, the session timeout for Traditional Web was still 20 minutes.

When the React Web App session timeout is greater than Traditional Web, there is a window of time where this error can happen. We reliably reproduced the issue by logging in with SSO, waiting for 16 minutes, then taking an action in the application, and logging in again. The app would redirect to the Users application.

The configuration for React Web App session timeout is under:

ServiceCenter > Administration > Security > Applications Authentication > Session Login Settings > Max Idle Time

The configuration for Traditional Web can only be adjusted with the FactoryConfiguration forge component. See this post about how to do it.


We have a security requirement for 15 minutes, so couldn't just increase the React Web App timeout back to 20 minutes; but that would be the easiest solution.

I hope this helps!

Kind regards,


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.