https://domain.com/pun/sys/dashboard/logout
I am getting this message when clicking on logout button. Need help configuring logout functionality. I am using OKTA based login. This message appears on the OOD dashboard.
That seems like an OKTA thing which I’m not too familiar with. I would explore OKTA settings and documentation.
In my okta configuration inside ood_portal.yml, I have set logout_redirect to “https://domain.com/pun/sys/dashboard/logout”
and on the okta side it is set to the same thing.
Is this the correct logout url for OOD?
Also I am running this in incognito mode. It is the same in normal mode.
It seems to be all configured from the apache side, but when I googled your issue, there are settings on the OKTA side that you can change like this one below.
Just confirmed with the OKTA team, we won’t be able to alter this setting as this would affect other apps as well.
Using
logout_redirect: “/oauth2/idpresponse?logout=https%3A%2F%2Fdomain.com”
When a user clicks Logout, OOD appears to initiate the logout, but instead of leaving the user logged out, they are immediately authenticated again. There is no login page or login button shown in between — the logout essentially results in the user being signed back in automatically.
Using
logout_redirect: “/oidc?logout=https%3A%2F%2Fdomain.com”
results in 404 error
using
https://domain.com/pun/sys/dashboard/logout
results in the first screenshot I sent.
Do you have oidc_uri set to /oidc?
it was set to
oidc_uri: “/oauth2/idpresponse”
I updated it to “/oidc”
and logout_redirect as
logout_redirect: “/oidc?logout=https%3A%2F%2Fdomain.com”
The same thing is happening OOD appears to initiate the logout, but instead of leaving the user logged out, they are immediately authenticated again.
I’m not entirely sure what could be happening. What does your OKTA team say? Is this expected behavior from their side?
Where does it redirect to once we click the logout button? Could you please share a screenshot?
and what is the logout endpoint?
In our setup the outlook accounts are linked to the user present in the OOD server.
so eg- my outlook account is Rishabh.Singhal@outlook.com which is linked to my user rsinghal (present in OOD server).
Since my outlook is always signed in, it tries to sign out but signs back in again.
This behaviour does not happen in incognito mode. In incognito mode I am redirected to login page.
using-
logout_redirect: “/oauth2/idpresponse?logout=https%3A%2F%2Fdomain.com”
Here’s what it looks like on my system with oidc_uri: /oidc and logout_redirect: /oidc?logout=https%3A%2F%2Fdomain.com
When you updated the configs, were you sure to bounce httpd. Also your oidc_uri and logout need uri need to match.
I.e., these 2 match:
oidc_uri: "/oauth2/idpresponse"
logout_redirect: “/oauth2/idpresponse?logout=https%3A%2F%2Fdomain.com”
or
oidc_uri: "/oidc"
logout_redirect: “/oidc?logout=https%3A%2F%2Fdomain.com”
Turning on apache oidc logging may help indicate what’s going on as well.
Note the domains in my image there. /oidc?logout sends me to my IDP which sends me back to my ondemand server which then sends me back to my IDP where I’m prompted to login.
I have tried both these approaches with apache restart.
The OOD portal never asks me for login.
One important observation:
When I launch OOD in normal chrome window I am facing the auto login after sign out issue.
In Incognito mode:
Its working perfectly, I click on sign out I get redirected to the login page.
How about clearing your browser cache for your site in a normal window? Does it prompt you for sign-in then?
- I opened the OOD portal (normal chrome window)
- Log in happened automatically
- Deleted site data and cookies
- Clicked on Logout
It does the logout procedure but then it immediately starts signing in. Its picking up the session cookies from somewhere.
I am running this inside a VDI and my VDI account is the same account that OOD and Outlook use.
I did a bit of research and one of the AI tools suggested me
"We have confirmed that OOD is correctly invoking the OIDC end_session_endpoint. The browser sends a request to /oauth2/v1/logout with both id_token_hint and post_logout_redirect_uri, and Okta returns HTTP 200. However, in a normal Chrome session, the user is immediately authenticated again when OOD redirects back to the authentication flow. The same OOD logout works correctly in Chrome Incognito.
The ID token shows idp: DSSO. Could you please verify whether the DSSO/Okta session is being terminated by the OIDC logout request, and whether the DSSO session can cause automatic re-authentication after logout?"
I’m not really sure what’s going on here. Maybe @tdockendorf knows more.
OnDemand relies on mod_auth_openidc for logout. If the Redirect URI:
OIDCRedirectURI /oidc
With mod_auth_openidc a logout is performed by going to the Redirect URI path but with logout query parameter so something like /oidc?logout=https%3A%2F%2Fondemand.osc.edu and that is how mod_auth_openidc handles logouts. If it’s not working with Okta then maybe an issue with mod_auth_openidc and what Okta expects. For OnDemand this is what our settings look like:
oidc_uri: "/oidc"
logout_uri: "/logout"
logout_redirect: "/oidc?logout=https%3A%2F%2Fondemand.osc.edu"
We figured it out.
In a normal Chrome window, the key factor appears to be Kerberos/DSSO:
- The user clicks Logout in OOD.
- OOD clears its local session cookie.
- OOD redirects the user to the Okta logout URL.
- Okta may clear its web session cookie.
- The browser is redirected back to https://ood-domain.com.
- OOD sees that there is no local session and immediately initiates OIDC login again.
- Okta receives the authentication request and, because DSSO is enabled, performs silent Kerberos authentication (SPNEGO) using the user’s machine/AD login context.
- A new Okta session is created automatically, and the user is immediately logged back into OOD.
So, the logout itself does happen successfully at the OOD level. The issue is that Kerberos/DSSO immediately authenticates the user again, making it appear as though the logout did not work.
In Incognito mode, logout works as expected because it uses an isolated cookie/session environment, without the existing Okta session or device-trust context.
We also tried logging out directly from the Okta dashboard, but the same issue occurs there as well — after logout, Okta automatically signs us back in through Kerberos/DSSO.
Planned approach
As a next step, we are planning to create a static HTML logout/landing page within OOD and redirect the user to that page after they click Logout.