We are in the process of implementing SSO with OIDC in several of our ASP.Net Core and ASP.Net MVC 5 (.Net Framework 4.8) applications, using the Okta-hosted redirect method. We have based our implementations on the sample applications provided and are using the Nuget packages supplied by Okta.
When an application session starts up, it starts the SSO handshake by calling authorize?client_id=XXX… the browser flashes through a sequence of images and messages, eventually loading the application as requested with no additional user actions required.
All applications behave normally for the first hour. When browsing the .Net Core applications, once one hour of time has elapsed the network traffic in the developer tools appears unaffected, i.e. the same session ID and cookie continue to be passed on each request and there is no further attempt to authenticate, provided the user’s ASP.Net 60 minute session has not expired and /or the Signout has not been called.
Conversely, in the .Net Framework applications, when one hour of time has elapsed, a page navigation shows in the developer tools that the authorize sequence is restarted, it proceeds through a series of “Probes” trying to contact various localhost ports, and then gives up and redirects to Okta password entry page, while still displaying the identity of the user. If I do a client-side call after 1 hour, such as refreshing a Kendo grid, a CORS exception is logged in the developer tools. Obviously neither of these scenarios is what we want or expect, we want the user to seamlessly and continuously be able to navigate the application as long as their ASP.Net session has not expired.
It seems as though the Core applications are doing some sort of “sliding expiration” that allows them to forgo the re-authorization process, but whatever is happening there does not occur in the Framework applications. I have tried various settings with UseCookieAuthentication and UseOktaMvc, but nothing changes, including with the sample application. The Okta cookie size is significantly larger in .Net Core, such that it is chunked into two cookies. The app session expiration based Signout occurs as expected and redirects the user to our Signout page. Signing back in from this page usually, but not always, works as expected, i.e. the normal handshake described above happens correctly, without additional user intervention.
I do not have access to the admin console (it is fiercely protected by the team that “owns” it), but I am assured that ALL of the applications are configured the same (and ostensibly correctly). So does this sound like a configuration issue in the admin console or the application, or do we need to manually implement something in the Framework apps to emulate what is done out-of-the-box in .Net Core? If we need to do a manual refresh, can someone refer me to a sample implementation? I have seen discussion of this elsewhere, but it does not seem to apply to the Okta-hosted redirect method.
We did not identify this problem as repeatable when doing the initial implementation and extensive testing several months ago, only recently did it appear or at least we only recently understood how to reproduce it reliably.
