We have an ASP.NET MVC application which uses Okta for user authentication. When an unauthenticated user browsers to our app, they are directed to Okta to login, and then they are redirected back to the application. When they click “Logout” within the application, they are signed out of the application and signed out of Okta.
The issue is when we click “Logout” from the Okta dashboard. When a user clicks “Logout” from the Okta dashboard, they are signed out of Okta, but they are not signed out of the application. When the user logs in with different credentials in Okta and open the application, HttpContext.User.Identity still contains the previous user information.
Is it possible for when a user clicks Logout within the Okta dashboard, to also log them out of the ASP.NET application? What’s the best approach for this scenario?
From what I’ve read before, single log out only works when initiated by the service provider. When you click on the Logout button in the Okta dashboard, it only clears your Okta session but not your application session. A possible workaround is to modify the “Sign-out page URL” under Settings -> Customization in the admin dashboard to point to the logout path of your application but this might only work if you only have to support one application url.
@warren - Thanks for the suggestion but unfortunately it won’t work for my use case. This seems like a big oversight on the Okta implementation, there should be a way for your applications to receive a sign-out callback from Okta.
Hey @thiag0, can you clarify on what your use case is? Some developers would argue for the opposite and they don’t want the user to be logged out of their application when they logout in Okta. I believe this ultimately depends on your implementation.
Okta does not support this option for closing sessions in all service provider applications when the user logs out from Okta.
The best solution in this case would be to implement a method in the view of your application which would check if the user is logged in to Okta using the CORS call available here and, if the user is not logged in to Okta, then close the session in the application.
I’m currently evaluating okta for our company. We provide for our clients different tools which are basically different web applications. Few years ago we implemented relatively simple SSO solution so that the clients can login through our company’s portal and then they can seamlessly use any of the different tools without logging in separately in each of them. Also, when they log out from any of the tools or the portal they are logged out everywhere.
With the advancement of modern security standards like 2/MFA it became necessary to look for more robust solution. I’m currently testing different frameworks, okta being one of them.
My own development led me to the conclusion that the access tokens are independent from the user’s web session and @dragos answer confirmed it. I was little surprised that okta made such design decision. Many users are used to have single control of their session among all their apps - it is enough to mention Google.
The variant @dragos suggests is one option. I’ve come upon different solution: at login the frontend makes the same CORS request (to GET sessions/me) but then submits the id of the session to the web app backend. Then the backend stores it in its own session and can check at every request (with GET sessions/{id}) if the session is still active. I find this to be a little more secure because it is not left to the frontend to decide if it should logout.
Yet, it’s little hacky to send the session id to the backend like that. My question is, is it possible for the backend to extract the session id without resorting to the frontend to send it? At first I was hoping that the access tokens should contain as attribute the session id that was responsible for their authorization but it seems this is not the case, as it turns out the sessions and tokens are fully independent.
Another question is if okta has plans to implement this feature more natively. Again - many users are used to work with Google products and signing out at one place to end all apps. This is practically a must when using shared devices. We should not burden the user to keep track of all apps used and having to logout all off them independantly.