After logging into my Angular SPA application, if a user closes all browser instances, and then eventually reopens their browser and navigates to the Angular application, they are then automatically logged in without having to supply any credentials.
Is this behavior expected? I could have sworn previously when closing the browser the session was cleared and it would prompt you for credentials the next time you reopen the browser and navigate to the application, but maybe I am misremembering.
I have my application authentication policy set to “Prompt for password authentication”/“Prompt for all other factors of authentication” “every time user signs in to resource”.
I have the Global Session Policy set to a time limit (I did 1min for testing, but that had no affect) and also the “Okta Global Session Cookies Persist Across Browser Sessions” is disabled
If anyone could point me in the right direction I’d appreciate it.
What happens if you access the Okta domain after closing the browser? Are you prompted to re-authenticate or are you let back in automatically there too? If the latter, did you check if your browser settings are causing the cookies to persist (I know you mentioned the policies are not set to persist)?
If you are prompted to re-authenticate if you attempt to navigate to the org directly, does the behavior go away if you clear all cache, cookies, local storage, etc and retry?
What happens if you access the Okta domain after closing the browser? Are you prompted to re-authenticate or are you let back in automatically there too?
Looks like I am prompted to reauthenticate when accessing our org oktapreview domain after closing the browser.
If you are prompted to re-authenticate if you attempt to navigate to the org directly, does the behavior go away if you clear all cache, cookies, local storage, etc and retry?
If I clear the cookies and local storage prior to closing the browser it prompts for reauthentication when I reopen the browser and navigate back to the application.
Hmm, sounds a bit like its the application’s session thats persisting then, not the Okta session itself (since these are handled separately, with the Okta org setting a session cookie on the Okta domain to manage its session and your application storing the users tokens to manage its session).
How are tokens being stored for your application? Are they added to Session Storage? Local Storage? Cookies?
We are utilizing the Okta Angular SDK/ Okta Auth JavaScript SDK to manage that for us. Versions 5.2.0 and 6.76 respectively
Our CallbackComponent (based off the OktaCallbackComponent) calls the OktaAuth.handleLoginRedirect(), so looks like it’s storing it in Local Storage.
I have figured out the issue. The okta-auth-js (v7.7.0) library defaults to localStorage for its token storage. See README. This default seems backwards to me. You would think having a more secure option as the default option would make more sense, but maybe I am thinking about this wrong. @andrea is there a reason localStorage is the default?
localStorage does not get cleared on browser close, so the session remains active the next time the user logins. I have now switched it to sessionStorage.
Also, a note for anyone that may find this in the future, if you are logged into the app, open a new tab and then navigate to the app this may prompt your user to re-authenticate. You can configure this using the authentication/global session policies in the Okta Admin Console. I have my auth policy set to prompt for re-authentication when the global session is no longer active. My global session then has a max lifetime/idle time.
I believe LocalStorage is preferred by the SDK as it allows the session to be shared across browser tabs (whereas SessionStorage is only available in the original tab), which typically provides a better end-user experience for any app where a use may have multiple tabs open.