So I’m quite new to Okta and have tried about a dozen different scenarios looking for the one that will work for my users. I had the Okta-hosted signin widget working but found a flaw in their code since if I timeout our users after 30 minutes of inactivity and send them the Okta signin page, after 15 minutes of inactivity there, signing in takes you to Okta’s 400 error page and our CSRs will get flooded with thousands of calls. So I went back to the self-hosted sign in widget and that scenario no longer is a problem. I have a new one though since each tab I open requires signing in. One of the major criteria I have to adhere to is the ability for users to reuse their token when opening any of our applications. That isn’t happening. Every new tab requires signing in. That brings me to my main point. Okta’s widget by default is storing everything in local or session storage including the access token. That’s a bad practice but I have no idea how to change that. I can call a backend method to store the access token in a table and delete the token from client storage, but I can’t seem to get the widget to let me get the token from the back-end before trying to check for it. I’ve checked the documentation and Google searched for days but haven’t found anything with example code. Is there some sample code that doesn’t use client storage for token management? Thanks!
When a new tab is opened, is it opened to the same domain/port? If yes the application would have access to the local storage and tokens.
If not the same application domain/port.
If third party cookies are enabled, the application could do a CORS request to check if a session exists, if so do a getWithoutPrompt call to get the tokens.
If third party cookies are not enabled, the app could open a hidden iframe and do an /authorize call to retrieve the tokens.
Other options could be storing tokens in your own storage provider. This provider could do whatever logic, like storing them in a table. Before the rendering the widget the storage provider could be checked first.
Another option would be to pass tokens from one tab to another assuming one of your apps serves as a sort of parent app for the other app(s).