search

okta / okta-auth-js

The official js wrapper around Okta's auth API
Other
447 stars 261 forks source link

token.getWithRedirect not happening immediately #1485

Open ogoley opened 8 months ago

ogoley commented 8 months ago

Describe the bug

Hello, I am using Auth JS and I'm noticing that the webpage that I am trying to protect is partially loading before the redirect happens, I have searched the previous bug/issues and saw one where awaiting the authClient.token.getWithRedirect but I'm still seeing the same behavior after this. Is there anyway to ensure a redirect happens immediately and the page is never shown before authentication?

Reproduction Steps?

I am not able to share the app that I am working on.

SDK Versions

7.2.0 - Auth JS

Additional Information?

No response

jaredperreault-okta commented 8 months ago

authClient.token.getWithRedirect results in a full page redirect, so there is no way to control how "fast" this happens. This is purely a browser function

However, how are you "protecting" your page? If your page starts to render itself and during bootstrapping it checks the current auth state, then I could see this being an issue. But if you check the auth state before rendering the page you should be able to prevent this. I'd need more details about your app to give a better answer. If you can't share details in a public forum, please feel free to reach out to support.

ogoley commented 8 months ago

Thank you very much for the quick response. I am not very experienced with okta or Auth JS, I have a solutions team that set things up and handed me this app to deploy. Upon deployment I noticed these issues. The app is simple html & vanilla js app that is hosted on AWS amplify. The solution that was come up with was to put the Auth JS script at the top of index.html in the head (which also has the 'sensitive' content on it) and run that script immediately to check for a valid auth token and redirect the page to the companies okta login page if not. It seems like you are saying this is inherently unsecure because the contents of the page have already been served. I think this is the problematic scenario that you described in your last comment. I guess my question now would be is there anyway to secure this kind of app in a similar fashion to what I'm doing or would I need some type of server/lambda function to sit in front of the app and check for authorization before actually serving the page?

jaredperreault-okta commented 8 months ago

It seems like you are saying this is inherently unsecure because the contents of the page have already been served

Exactly, however this depends on what is exactly on your page. If your page needs to confirm auth state before requesting resources from an API, then presumably the only information you're "leaking" is html structure (probably not a huge deal). If your page is pre-built (rendered on a server for example), this may be a greater concern

I guess my question now would be is there anyway to secure this kind of app in a similar fashion to what I'm doing or would I need some type of server/lambda function to sit in front of the app and check for authorization before actually serving the page?

I'm not familiar with AWS Amplify myself, however it seems to have authentication capabilities built in: https://aws.amazon.com/amplify/authentication/?nc=sn&loc=3&dn=1

If you'd prefer a browser/frontend solution, I think the "security" of your app is a function of what will be rendered on the page before the auth check (aka what html already exists)