PatrickInBama
I’m having to replace our in-house authentication process with Okta and I’ve tried 6 or 7 different process from Okta-hosted widget to custom self-hosted widgets and I think I have found the right combo but have issues with the sdk. So one of my criteria is token reuse. Customers want to login one time and opening other products of ours should reuse the token. We have 6 or 7 products in our line and today each requires you to login. I did have this working with the Okta-hosted widget but I found a flaw in Okta’s code that is a showstopper so I went back to the self-hosted widget. FYI, the showstopper is a scenario where we have a session monitor that monitors activity and after 30 minutes of no activity signs you out and takes you back to the sign on page. Okta has a flaw where if someone were to go to lunch and the session times out, after 15 minutes of sitting on Okta’s signin page, Okta loses track of the originating app so you get their default 400 error page or if you do login and have a subsequent MFA screen to authenticate with and you sit there for 15 minutes, successful re-signing takes you to the Okta dashboard instead of you app. Our users will flood our CSR with thousands of questions.
Any way, the issue I have now is I used Okta’s basic signin widget which works great, but I think it’s missing features. I don’t have the ability to reuse an existing token…each subsequent tab requires logging back in. Worse though is why I’m writing this reply. You hint at using Okta instead of localstorage, yet Okta uses localstorage to store all tokens. Isn’t that a bad practice? With an access token, any hacker has all they need to hack your application. Yet, none of Okta’s documentation ever mentions how to replace their token storage with something more secure. Their widget will break if you move your storage provider to a custom one. What ideas do you have to help me replace Okta’s default token storage with a custom storage provider that is more secure?