[Question/Suggestion] Default Token Storage Type

[lukaszkostrzewa]

Describe the feature request?

The Okta Auth JS SDK stores tokens in Local Storage by default. According to the OWASP guidelines, storing sensitive data like tokens in Local Storage is not recommended due to the XSS attacks¹². Also, Auth0 recommends browser in-memory storage for storing tokens securely (using Web Workers or JavaScript closures)³.

Have you considered changing the default token storage type to browser in-memory storage? This way, the library would promote secure token storage by default, and developers would have to opt to use Local Storage. Unless there were any specific reasons for choosing Local Storage as the default storage type?

By the way, the library is great! Thanks for your work! 👍

New or Affected Resource(s)

Okta Auth JS SDK

Provide a documentation link

No response

Additional Information?

No response

Footnotes

1. OWASP HTML5 Security Cheat Sheet ↩

2. OWASP JSON Web Token Cheat Sheet for Java ↩

3. Auth0 Token Storage ↩

[jaredperreault-okta]

Our Security Team at Okta has reviewed our usage of LocalStorage and has given it a 👍 . We would remove it from the SDK, if it was found to be insecure

An important consideration here is the User Experience (UX). Ultimately both, in-memory and localStorage, are viable approaches, but they produce different UX. Tokens stored in memory-only will only be available as long as the web page is active. If the user refreshes the page, the tokens will be forgotten. In-memory storage also does not sync between browser tabs. Users will expect authentication to persist across tabs and a page refresh. Using localStorage, solves both these UX problems, but is more vulnerable to XSS attacks rather in-memory.

This concept is sometimes better understood through an analogy

1. If I lock $20 in a lockbox and throw away the key. The $20 bill is "secure", however I will never be able to access the $20 again.
   a. Too much security negatively affects UX
2. If someone has broken into my house, does it matter that my keys on the table by the door?
   a. XSS are a break-in. Rogue code is executing in your web app. It can do (and has access to) anything the web app does. The tokens may be the least of your worries in this scenario

Our default storage location is localStorage because it provides the best UX and reasonable security controls. Additional controls (as the A0 doc mentions) can be applied to improve your security posture

1. Reduce the usage of third-party scripts and using SRI can reduce the likelihood of XSS from occurring (good advise in general, regardless of tokens)
2. Set a short expiration time on accessToken, so if they are compromised the exposure window is small
3. Enable DPoP to bind tokens to the client which requested them. Even if a dpop-protected token is compromised, it will be unusable